One of the interesting things about architecture is how everyone is willing to say something about it yet so many of them limit themselves to their own area of expertise. So you get SOA architects, infrastructure architects, BI architects, process architects, business architects etc. While narrowing your scope to what you feel you can contribute to seems to make sense, such a narrow scope has a consequence: a company will have an “infrastructural architecture”, a “process architecture”, a “BI architecture”, etc. Essentially, we’re creating a sort of ’stovepipes’ of architectures, where the boundaries are determined not by the organization’s best interests, but by the limits within which its “architects” feel safe.
To me, the most flagrant example of this are the disparate architectures for a BI solution and for process support. BI and process automation are two fields where my employer excels in. They’re also very closely linked. To me, it makes no sense at all to consider an architecture for one without at least knowing the key points of the other’s architecture. Consider, for example, the following points:
- Intelligence systems are mostly fed with data derived from a company’s operational and supporting processes.
- Intelligence systems are used directly in the execution of some processes. Think, for example, about the possibilities of feeding a knowledge worker with information about the consequences of previous decisions he made. Or the possibilities of complex event processing, which requires the capability to identify and recognize patterns as they occur.
- Processes can be improved in BPM or BPR projects based on information from intelligence systems. Round-trip engineering and simulation are two, very, hot topics covering this at the moment.
- Operational processes can give a context within which to judge information derived from an intelligence system.
And I’m sure that’s not all of it. Simply said, one cannot be regarded without knowledge of the other.
That’s not to say that there are no parts of an architecture that are specific to one subject area. The specifics of how to design a data warehouse is of no interest when designing a process application. However, the architectures influence each other, and choices made in one will influence the degrees of freedom that can be offered in the other. This is why they are not separate but linked.
Let’s look at an example. Say that I design a “BI architecture” – an architecture that deals with the way information is spread and used in the organization. Part of my BI architecture concerns the way data moves from operational systems to intelligence systems – the ETL process. As my organization is light on knowledge workers, we envision a mostly management-centred intelligence systems that aims at monthly reports. For efficiency reasons, the choice is made to only move through the ETL process once a month as well.
At the same time, a process architecture is set up separately. At the foundation of this architecture is a process redesign effort in which more responsibilities are given to the workers executing the process. In essence, the process architecture envisions a shift to knowledge workers. Of course, these knowledge workers will need more and more recent information; preferably real-time. Unfortunately, our new BI architecture will not be able to supply this.
While this might be a fairly simple and straightforward example, reality offers far more complex situations, with many more aspects, consequences and subject areas that will have an influence on each other. It is, of course, undesirable (and impossible) to consider the entire organization every time you wish to make a slight change in one aspect. Preferably, that’s the role of enterprise architecture: to lay down the degrees of freedom for the more concrete architectures to operate in. But if those boundaries are not set, at the very least an architect can consider how their own choices influence the options left in other architectures to achieve the goals and implement the strategy of the organization as a whole.
I guess it all comes down to the same basic thing again, doesn’t it? Communicate, share & cooperate!
