Our people weigh in on the issues of the day.
Blue Slate's people think a lot about the challenges facing their industries today. In the process, they often come up with completely unexpected slants on current issues, or new ways of thinking about business problems. Bluespeak is where they share those thoughts. Feel free to read and reflect.
[Any views or opinion represented in this blog are personal and belong solely to the blogger and do not represent those of Blue Slate Solutions.]
For years we’ve been hearing about the importance of Enterprise Architecture (EA) frameworks. The messages from a variety of sources such as Zachman, TOGAF, HL7 and others is that businesses have to do an incredible amount of planning, documenting, discussing, benchmarking, evaluation, (feel free to insert more up-front work here) before they will have a good basis to implement their IT infrastructure. Once implemented all the documentation must be maintained, updated, verified, expanded, improved, (once again, insert more ongoing documentation management work here). Oh, by the way, your company may want some actual IT work aligned with its core operations to be accomplished as part of all this investment. I don’t believe such a dependency is covered well in any of the EA material.
I have always struggled with these EA frameworks. Their overhead seems completely unreasonable. I agree that planning the IT infrastructure is necessary. This is no different than planning any sort of infrastructure. Where I get uncomfortable is in the incredible depth and precision these frameworks want to utilize. IT infrastructures do not have the complete inflexibility of buildings or roads. Computer systems have a malleability that allows them to be adapted over time, particularly if the adjustments are in line with the core design.
Before anyone concludes that I do not believe in having a defined IT architecture let me assure you that I consistently advocate having a well-planned and documented IT architecture to support the enterprise. A happenstance of randomly chosen and deployed technologies and integrations is inefficient and expensive. I just believe that such planning and documentation do not need to be anywhere near as heavyweight as the classical EA frameworks suggest.
So you can imagine, based on this brief background, that I was not particularly surprised when the Zachman lawsuit and subsequent response from Stan Locke (Metadata Systems Software) failed to stop EA progress within Blue Slate or any of our clients. I’m not interested in rehashing what a variety of blogs have already discussed regarding the lawsuit. My interest is simply that there may be more vapor in the value of these large frameworks than their purveyors would suggest.
For starters, the EA design process must cost far less than the actual hardware and software; remembering that cost isn’t just the purchase price but also things like the time to implement. Fundamentally, I don’t believe you can avoid basic issues such as throwing the first one away or the second system effect without the right people involved, regardless of any framework.
Further, the logical and physical manifestations of the IT infrastructure are less important than the governance and processes responsible for utilizing that infrastructure and its services. Whether dealing with deployment and maintenance, software development and COTS purchases or any other IT-related operations, what matters to obtaining business value from IT investments is how budgets and priorities for the IT assets (people, hardware, software, vendors, and services) are controlled. To be fair, the frameworks have added these concepts over time.
Another part of my suspicion around EA and its set of certification and training companies is that the practitioners do not need to be experienced with the underlying technologies. EA experts are not precluded from having such expertise, and I’m sure there are very good enterprise architects who have hands-on technology skills and framework expertise. However, there are also those that have only the framework background which can lead to a lot of diagrams and subsequent hope that the actual hardware and software play as the diagrams demand.
This approach works in pure engineering fields where tools exist to predict and model, with mathematical certainty, the result of a given design. A mechanical engineer can use finite element analysis to guarantee the stress behavior of a part made with a specific material. However, the stuff of enterprise architectures do not have such mathematical models available nor do we have tools that allow us to describe the exact design of a desired system and then predict the absolute data flow, disk i/o and so forth of the resulting system. With EA we need to apply real-world hands-on experience to inform our design.
Logically, I don’t buy into the need for such broad and deep up-front documentation. This opinion is based on life in the physical world. Certainly when dealing with town planning one would expect that a great deal of thought and documentation is completed before installing expensive and permanent infrastructures such as roads, water and natural gas piping, telephone and electrical wiring as well as laying out neighborhoods, parks and commercial zones.
What is interesting is that towns do not do this planning and documentation work to its completion before actually building things. They take care of macro items and understand that the plan will change over time. Processes such as zoning variances, creating paper roads or leaving land aside for future use all exist because people have come to understand that there is a point of diminishing returns when pretending to design the entire picture.
This limitation is also true with IT infrastructures. There are key best practices that can be leveraged. The corporation must layout a solid governance process with effective leadership to begin the journey to obtaining measurable value from IT. That leadership will be in a position to assure that an architecture which is built and supported in the best interest of the business will be achieved. The enterprise architecture plan at this point will be high level – best practices and key technologies – all based on what the business needs.
Such an approach does not lead to massive amounts of documentation. Instead the result is a set of iterative projects, some focused on the infrastructure and some focused on advancing business operations. How can companies discover best practices and meaningful guidance around good technology choices? From their peers, industry experts, case studies from related industries and yes, experienced consultants who have seen a variety of solutions, both effective and less so.
Fundamentally, portions of these frameworks have value. A task for IT leadership is to cull out the artifacts that will benefit the business’ IT investment and use those to create a meaningful roadmap. Base these choices on the acceptance of the fact that the IT architecture will change over time as the business environment and technology options change. This alone is a great reason to pick and choose the relevant framework artifacts carefully since they will need to be maintained in order to have any value.
I would enjoy hearing from others about their use of formal EA frameworks. What features within them helped advance your IT infrastructure? Were some artifacts more or less useful? Have you worked with EA experts who did or did not have product or implementation experience? Did such experience make a difference in how the EA framework was applied?