Enterprise Architecture: The more we change, the more we stay the same
October 25, 2011 10 Comments
Last evening I started reading Business Architecture, Ulrich & McWhorter. I was amazed at seeing the concepts I once extolled over a decade ago in my ZIFA presentation in print. My mentor John Zachman back then had asked several provoking questions prior to then. One was just confirming completeness his model of IT Architecture. This was when time and motivation columns where not part of the framework. We had several days’ discussion about what do time and motivation artifacts look like.
I would fall back to my dwelling architecture career of the past to answer; building schedules to name one, project plans to name another; both are concern with time or precedence of activity. But is it important enough to be a dimension John asked. It fits the reporter’s interrogatives: Who, What, Where, When, Why and How that I believe should be the columns. “Did you ever think how hard and expensive it is to put a roof on a building without walls or a foundation. It can be done, but it’s costly.”
The next one had to do with span and depth of Architects. This was one of the most enjoyable discussions I had with John. I had brought an old Architecture text book, creating architectural theory, Jon Lang. In it Lang had described different levels of design, the span and granularity that architects of various types dealt with. An Urban Planner is not about to design your house and his work products are likely to affect people for generations, look at how various city growth patterns. These were established decades ago.
Enterprise Architecture is much the same way. Many corporations’ architectures are still the same, despite the addition of information technology. These companies may or may not need to change depending upon the ecosystem they reside in. However, as ecosystems start to interact with other ecosystems –think globalization—business models and architectures are exposed to others which may be more competitive. Consider the “Japanese Auto Invasion of the 70s”, was it cheaper cars though cheaper labor as the Detroit elite suggested or was the old mass production model breaking down in the like of a different business model. History now confirms the later.
When I present on Enterprise Architecture around the global, I still use the analogy of dwelling architecture. The example I typically use to differentiate architecture from design and there is a difference is the various Gothic Cathedrals. If you overlay them on top of each other each is different. So it’s not the stone, glass and wood, but how you use these that determines an architecture. These rules (Design Strategy aka Architecture) determine how the components relate to each other as well as usage of these as a system.
Going back to my technology example, consider the telegraph. During its introduction it changed how business work around the nation and eventually the globe. Now consider the next advance in communications technology, the telephone. Initially productivity didn’t increase with its introduction. Why? Consider the old –in the relative sense—paradigm of the telegraph in business usage. A business owner or manager would dictate a memo to secretary; she would courier it over to the telegraph office where it would be translated into dots and dashes; at the other end the dots and dashes would be translated back to text; couriered to the recipient business’s secretary who would read it to the business person. Enter the phone; a secretary would take dictation then call the business at the other end, the two secretaries would exchange pleasantries and then dictate the information; which was then either handed to the other business owner or read to him. During each of this information exchanges misunderstanding and transcription errors could occur. A simple business transaction could take several days of back and forth.
It wasn’t until two business people broke the model and spoke directly to each other that a competitive advantage ensured. Those business people that used the technology in a different way become more competitive.
Back to Ulrich & Whorter, they rightfully point out that SOA and Cloud are hyped as the next Holy Grail. I believe they miss the mark though by tagging vendors and IT groups as the black hats in this story. These stakeholders are both part of the problem and the solution. However, business people share a lot of the blame as they continue to look for the silver bullet so they don’t have to think about managing their information or constantly reviewing and revising their business models. Vendors and IT groups deal with information technology, not information management. If you substitute drill presses, stamping machines, and an assembly line for servers, networks, databases and browsers we’re back to its not the stone, glass and wood but how you use them. Vendors and IT shops are good to great at dealing with the mechanics, not so good on defining business models. This is where Enterprise Architects come into play. Unfortunately too many EAs are not EAs; they have the title but not the orientation. They’re just technology or infrastructure architects with an inflated title.
Failure to understand how to use the new technology in a new way will result in the creation of what my friend John Mancini of AIIM has labeled the Digital Landfill and create more of an Information Glut (think of hardening of a corporation’s knowledge arteries).
You know you have an EA on your hands when s/he looks at business models & goals, economics, technology paths, organizational capabilities and how to translate these into a series of state changes for the company.
What I still see on the horizon is Information Management Maturity. Today I see signs that some organizations are seeing that need. 2020 Roadmaps talk to managing information more like assets. Disciplines like Information Architecture while popular are still in its infancy, you’ll hear terms like taxonomy and ontology however, these are just exploratory projects in many corporations. Technologies like SharePoint that could exploit the design intent that these terms represent are left waiting for the discipline to mature as well as a strategic execution system to deploy.