Are Better Business Architecture Abstractions the Key to Enterprise Architecture?
After a decade of formal "Enterprise Architecture", the discipline is still looking for a solid foundation. Most companies know they have to do it, they do it, but they are still debating why and how.
JP Morgenthal argued a couple of months ago:
enterprise architecture for the sake of doing enterprise architecture is a seemingly valid and important activity, but in retrospect flounders aimlessly in search of respect. We hear it consistently throughout the industry—EA gets no respect...EA struggles to be recognized for its strategic importance.
- Stop trying to make the rest of the world see the importance of EA and just make sure it’s a critical component of any transformational task
- IT needs to start thinking more like the business and less like engineers
Ian, "IT Blagger 3.0", a Cloud Architect at Fujitsu, expanded JP's arguments.
EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role
In his organization, Ian developed a business capability map as a portfolio of business components. For him, the understanding of how these capabilities are delivered are not necessarily an end in itself, few people need to know that level of details. He feels that it is more important to understand the purpose and broad outcome of each capability. For Ian the next level of details need only to be captured as new programs require them.
we kept an approximate portfolio view of the assets in the organisation (so for example processes, number of people, roles, applications, infrastructures and data) as horizontal assets along with the fact that there was some kind of relationship but these were only sufficient to allow reasoning about individual capabilities, broad systemic issues or the scale of impact of potential changes and were not particularly detailed
The bottom line is, in his opinion, that it is impossible to keep a centralized view of how the enterprise works -at a cost that would justify the value of such a view. He also argues that the traditional views of EA (People, Process and Technology) are too simplistic to support the diversity of business models. He argues for creating business architecture assets targeted at different levels of abstraction and produced in a contextually appropriate way to facilitate a far greater federation in decision making and implementation.
Effectively a framework for understanding and actionable insight is far more valuable than a mass of – mostly out of date – data that causes information overload, confusion and inaction.
For him, you can no longer afford to ignore the ecosystem in which the enterprise operates, from an EA perspective. You might even start to rethink the role of the Cloud, from being merely a Computing utility, to providing the realization of business capabilities in a more open and collaborative way than traditional IT can deliver. EA organizations that operate in a detailed oriented centralized way would not be able to think at that level and therefore take full advantage of the cloud.
The debate on the value, role, and approaches of EA will probably go on for quite a while, but after a decade of trials and errors and the pressure of Cloud and Mobility on business architecture, it is probably time to take a hard look at your EA organization. What's your take on it?
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015