As a consulting solution and enterprise architect, I frequently need to explain what I do – and don’t do. Too often recruiters and agencies ask for an architect without understanding the role.
The universal business model underpins my approach to enterprise and solution architecture.
It’s a common misconception that user stories replace use cases or traditional requirements specifications in agile development.
Be warned! SAFe is not a development process. Neither is Scrum. And agile development isn’t either. So, if your organization doesn’t have an underlaying development process, going agile, using Scrum or adopting SAFe won’t make your projects more efficient or successful.
Need a practical template for your solution architecture document? Feel free to use mine! If you are a stakeholder in a development project, demand that the project delivers architecture documentation that meets this standard.
Observability is an alarmingly underestimated quality of solution architecture, because it’s never the ‘business’ who asks for it. But it’s absolutely essential for achieving good auditability and operability, and it helps you monitor your capacity, performance and availability.
A handful of publications, some initially published in my early career, have significantly shaped my approach to solution and enterprise architecture.
When advising clients on enterprise architecture, helping them implement and integrate ERP and CRM systems, or developing new software for them, I’m often asked to review their enterprise architecture, and sometimes help them document it.
As an architect, it helps me having started my career as a developer. But architecting rarely leaves room for doing any of the hands-on development myself, so I develop on my spare time to keep up with the developers I work with during office hours.