I recently caught up with John Willis (co-author of the DevOps handbook). We were both on a call with a client and after that hosting the CNCF & DevOps Meetup in Wellington with our good friend BMK. On that day the good old question “Do organisations need Enterprise Architecture (EA) in times of Agile & DevOps?” came up again.
The timing for this question was perfect, because I spent many years in Enterprise Architecture and Agile, while Johns background is obviously DevOps and Agile, but we both have the same view: Yes, absolutely! And here’s why.
What is Enterprise Architecture?
This question is fundamental, because once you understand what Enterprise Architecture is you can derive the answer. The problem with the original question is really homemade.
Because many organisations call some of their architects Enterprise Architects, when they are really not, causes confusion. If you are looking after an Enterprise wide virtualisation platform for example you are NOT an Enterprise Architect in an Enteprise Architecture sense. I’ve written a more detailed piece on the different types of architects here.
Simply put, an Enterprise Architect helps define mission, vision, goals and the strategies to accomplish those goals. Mr & Mrs EA then help determine which capabilities (people, process & technology) the organisation needs to build in order to be able to execute the strategies that help accomplish the goals. A great framework depicting how this fits together is the means-to-end framework:
The ‘Tactical’ layer defines the programs, projects, products and services (i.e. initiatives) that build or uplift the desired capabilities. You can of course also find more scientific definitions of EA on the internet, but this is a simple and practical explanation of what EA is which works well for me.
And now I am handing over to Agile and DevOps
And that’s the moment where Agile and DevOps comes into play.
DevOps principles and the Agile way of working are methodology options (just like manual & waterfall) how you prioritise, define, build, test and deliver capabilities or capability uplifts. You could call Agile and DevOps also ‘enabling capabilities’ if you like.
And that’s really it. Simples.
Now, it’s easy to see how things get confusing when people who write Java Enterprise Edition (J2EE) based software get referred to as Enterprise Architects. But the problem is not with Enterprise Architecture, the problem is that those people are simply not Enterprise Architects.
If such a confusion exists in your organisation or with your customers, it might be worth running a workshop and getting the categorisation and scope of all the architects in your organisation examined and clarified. Examples of different types of architects are: systems, software, technical, infrastructure, operations, presales, delivery, business and enterprise architects.
Get them in a room to land on a common definition and understanding. It might get heated, but that’s OK. Terminally nice is way worse than passionate, respectful exchanges.
Keen to get your thoughts,
Andreas
Great article. And where strategic business units, EA and the PMO work together, that vision can be more easily obtained. By layering organisational goals and objectives across and down through the portfolio to programs and projects your plans can achieve a clear line of sight.
Strategy is a also a process, and like other processes it’s cross functional. I wonder how many businesses trace and effectively measure its actions and results to the Capabilities and ultimately people, processes and tools it aims to implement or change. To do that Strategy, the PMO and EA should operate as partners. Perhaps even as a team.