This in itself is no news obviously. The bigger an enterprise gets, the more likely it is to waste money due to the introduction of management layers and function decomposition. What is function decomposition you ask? I am not sure it is a proper business term, but in programming languages it is defining the value of a function as the value of other functions. This can generally be done over multiple levels and potentially create an infinite loop.
When you perform function decomposition, you create a set of dependencies between these functions. The original function’s value will now be defined as the result of the entire chain of underlying functions. The problem with this is that it is hard to maintain the exact definition of the original function if that of any of the others changes. I.e. it is becoming hard to ensure the correctness of the first function.
Additionally, the functions in the ‘middle’ of the decomposition chain originally have no meaning, except to the first function that calls them. After all, they are responsible for performing part of its task. The risk that rises from this decomposition is the fact that these functions may eventually be used elsewhere and because of that require slightly different functionality. Does this influence the first function?
Okay, enough theoretical babble, what does this have to do with enterprises wasting money? Well, function decomposition happens in enterprises as well. Take for example the task of creating and maintaining the overall Enterprise Software Architecture. In a small company, you will generally see exactly one person who keeps the helicopter view and who knows about everything that is going on. They have an easy task responding to changes and they can oversee all the implications such a change may have.
Now take a large enterprise. In a large enterprise, there is generally a team of architects that is responsible for this. Sure, two know more than one and three might be even smarter. The problem here is function decomposition. The task of maintaining and overseeing the architecture is handed over to four or five people. Should not be a problem, right? Wrong.
A large enterprise generally has many projects running that all have a relationship to the overall architecture. Since we now have a team of architects, it sounds like a plan to divide these projects among the architects. Great, divide and conquer. Now let’s assume the team of architects have all come together to decide on a roadmap for their enterprise’s architecture. They will have to come to some agreement about all the points that make up this architecture. With a team, there will always be a discussion, there will always be differences in opinion and in skill levels. This inevitably leads to compromises and potentially to silly conclusions. But, for this exercise, let’s assume they eventually agreed and created a single vision.
Now they will each go and attempt to make sure their projects adhere to the vision they have defined. Here comes trouble. Project X can not possibly adhere to the architecture, because of legacy component Y. A likely response is: “Well, darn, I guess I’ll have to make an exception for this project in the architecture. I’ll take it to the next meeting with my fellow architects.” Chances are that this architect will:
- forget he gave this permission, the exception will not be documented
- bring up the exception in the next meeting, but his colleagues do not agree, some compromise will be arranged
- bring up the exception in the next meeting, his colleagues do agree and the exception is documented
Now, in all three scenarios there is a waste of money. If the exception will never be documented and projects will be allowed to ‘forget’ about the architecture, then what use does this architecture have? If the exception will be compromised, the project will still have to change something and the architects probably spent several hours (if you’re lucky) arguing over this. If the exception is allowed and documented, you can be sure that the next project will also assume it will get exceptions when necessary. Again, why bother with the architecture?
In my vision, Enterprise Architect can still be a single function. After all, he or she is only required to maintain a helicopter view of the application landscape. There is no need to know exactly how all the applications work, or even on what technology they are built. In my vision, an Enterprise Architect should only concern himself with themes inside the Enterprise. Themes like these:
- Do we buy or build?
- Do we allow, need, restrict or forbid disparate hardware platforms?
- If we develop software, do we restrict the development platforms?
- For any third-party software (products, middleware and libraries), how does a project select a product?
- Which architectural patterns do we strive to use for inter-application communication?
In my experience, enterprise architects try to enforce too many technical choices on a project. They tend to step out of their helicopter and tell the construction worker which hammer he should use. Or even worse, that he should use a screwdriver to put a nail in a board. Instead, they should trust the worker to put the door where it is in the drawing, after all that’s the construction worker’s job, right?