Enterprise Architecture (EA) is very much on the agenda at dedicated conferences and many good articles are published. However, it is also evident from such events that the understanding of EA varies a lot, and so does the view on how implementation can be scoped.
EA projects are often initiated by company IT architects who still, typically, represent the architecture competencies in our companies. The problem with this is, seen from the Value Driver Model©, that this clearly is bottom-up work from the "Capacity Management" perspective. Such initiatives have no change of going beyond IT architecture if not a solid BPM initiative is launched simultaneously, providing the Value Driver bridge in "Balancing".
Luckily, a lot of larger companies understand the connection between BPM and EA but the way of handling this is too often seen in letting IT lead on also BPM. This maintains the problem of working bottom-up and at the same time, very likely, compromises the initiatives in the eyes of the core business.
We can therefore conclude, applying the concept of the Value Driver Model©, that both BPM and EA, being mutually supportive, should have strategic business ownership during implemetation and work top-down once fully mature.
Accepting that EA is not an IT discipline a proper definition should guide an EA and BPM implementation programme. Like for BPM many EA definitions exist trying to cover all the different essential aspects of EA. One such is the definition by Gartner quoted below which very comprehensively describes the complex nature of EA.
At End-to-End we will take advantage of our Value Driver Model© and define EA in this short way:
"EA is a systematic repository of validated information required for managing
value creation in the Value Driver Fields in the Value Driver Model©".
Process Architecture is at the very core of an EA. Without a Process Architecture we have no connecting structure linking the various elements of an EA together, this being the IT-architecture, the information architecture or the organisational structure itself.
We describe elsewhere how the ownership of processes and IT-solutions is a battlefield for IT specialists and low-level business users. The same goes for higher levels where a similar power balance exists when it comes to business integrity and the ownership of IT (and other) capacities.
To balance the relationships a Business Process Architecture is needed. To establish this, one element is critical - the understanding of the process levels.
It is tempting to conclude that the way to start a top-down development of a picture of business processes is by establishing an organisational ownership of these at high level. However logical this might seem, evidence shows that a company-wide Business Process Architecture is unlikely to deliver the expected company benefits if it starts at the top by dividing the ownership of main processes among functional divisions. With such a starting point it is typical for companies to break down business processes further according to the divisional structures. This leads only once again to divided silos and this, we already know, does not work.
Sometimes the solution to silo-problems is promoted as being the establishment of a process-organized business structure. This is, unfortunately, also an illusion.
Two obvious problems with establishing a one-to-one relationship between business processes and organizational structures exist. First, if the breakdown of processes follows the breakdown of business responsibilities there is no difference between "what" and "how". This can be OK at very low level where we are talking about working instructions and a particular output, but such business process understanding is not Business Process Architecture thinking. The wall-to-wall value creation is out of focus.
Secondly, process value chains are supposed to show how value ideally is generated in an organization. The very logic option to consider if an organization is not functioning optimally, will be to adapt the organization to optimize the business processes. If one of the consequences should then be to re-build the process architecture according to new structures, the possibility to evaluate the changes afterwards from a process and value perspective will be lost. This is, as clearly stated in the Gartner difinition above, an essential idea of EA and the included focused architectures.
With reference to the Value Driver Model©, the above approach means building an architecture with a narrow focus on only the Value Driver Fields "Line Management" and "Optimization". The linkage between the two, the Value Driver Field "Balancing" is ignored and in addition "Value Management" as a Value Driver Field and as a discipline is not acknowledged.
Without the clear picture of how our company works we have no knowledge of how value is created. And if we misinterpret the way we work and do not maintain performance history, we don't know where we are going. Thus, Process Architecture can be described as a "performance compass" which can keep our companies on track.