Not blowing up on the launch pad
There is no doubt in my mind that the subject of enterprise architecture is important, relevant and necessary, but there are a few cultural things that can threaten EA efforts right on the launching pad.
- Enterprise architecture must be made and kept practical. There is nothing impressive about a subject which is a mystery to your coworkers. If they cannot understand the subject or cannot see the practicality of the effort, there is no way they can help with or have the incentive for furthering the cause. Enterprise architecture is practical because it effects everything it involves (including the people) directly on a day to day basis [see Enterprise Architecture Distilled]. Demystify EA, and keep it practical.
- Enterprise architecture has almost nothing to do with technology. The fact that this point is generally misunderstood is one of leading reasons that EA efforts fail. Most EA efforts are started by IT departments. This is natural because IT tends to feel a lot of pressure for business investments in technology to deliver on things like integration with existing systems. In order to deliver IT finds itself asking EA related question because IT EA is only one specialized abstraction removed. The problem with IT attempting to decipher the EA is that, as members of IT, we tend to be technologists who eat, sleep and breathe technology. This mind set has two dangerous effects: first, we spend a lot of time thinking about this or that technological solution, and less time think about the true business concerns (from a business perspective). Second, many of us cannot remove ourself from world of acronyms, buzz words (like “Enterprise Architecture”), and techspeach which doesn’t mean much or anything to the business outside the IT department. More often then not IT staff is ill equipped to effectively communicate; rendering the effort void. When working with enterprise architecture, take off your technocratic hat. Enterprise architecture has to do with systems (automated and manual) not technology per se.
Enterprise architecture distilled
What does enterprise architecture mean? Well, let’s concern ourselves with the first word first (makes so much sense). John Zachman [the father of EA] can be quoted as saying “The system doesn’t merely support the enterprise, the system IS the enterprise“. The enterprise is composed of the systems in its domain.
Architecture is the practice of design.
If you translate system(s) to mean the people, processes, procedures, and assets/information, then enterprise architecture can be distilled as:
Enterprise architecture is the design [model] of the people, processes, procedures, and assets/information [system(s)] within a domain.
This definition gives some insight into the magnitude of enterprise architecture, but it does not overtly justify it. In many cases today, systems are defined in vacuums. We have been building enterprises this way since the beginning, why change now?
Technology is the latent catalyst for this change. I know that in the beginning of this article I said EA has almost nothing to do with technology, and it doesn’t. However, EA has to do with systems and as time elapses more and more of our systems are implemented with technology. As technology gains traction as the implementation of choice, and as it grows in capability its role in terms of the enterprise is changing. When technology began to take it's place in the business space, it was used to support business and foster local efficiencies. Today the role of technology in the enterprise is fundamental, and deeply en-grained. In many ways technology does not support the business; it is the business (you are what you eat?).
With today's technology comes capability and expectation. Businesses invest huge amounts of money in IT systems hoping that technology will deliver on its promises. When these investments fall short on their promises, business wants to know why. Technology, more then other implementations is subject to entropy, yet it offers the greatest potential. Entropy cannot be stopped; it is a fact of technology. Businesses have been looking to harvest the great potential of technology, while underestimating the effort required to fight it's entropy. The miscalculation is likely due to the fact that we have never experienced the kind of grow we have with technology, and we have not yet come to terms with the fact that it now plays a major role in the foundational space of or enterprise. Strategy is the slowing agent in terms of entropy, and the lever when it comes to realizing the promises technology has to offer.
Technology is not the reason to model your enterprise. Technology is only the implementation. Even a pen and paper business would do well to model their business. Models enable us to create strategies for tomorrow and tactics for today.
As the demand for greater integration, higher efficiency, and lower cost continues to accelerate it is impossible to design in local vacuums of concern and still deliver the goods. Know that these demands will never decrease; a business that can not navigate these absolute requirements will not be able to survive as the information age progresses.
What is in our way?
Enterprise architecture efforts have many things that seem to impede them.
- We never did it before, why start now?
- We don’t know how to do it.
- Once we get started, we see how difficult it is.
What is in our way; is us. What we stand to loose by impeding ourselves is practical, sane business practice, and competitive advantage.
Technology holds the key to leverage. To understand technology as the key to leverage, one must consider how it's role has changed in the enterprise since the dawn of the information age. We no longer simply use technology for localized improvement of a particulare process or domain (which has only a linear effect in terms of growth), we now rely on technology in such a way that it has the capability to radically effect global phenomena within the organization, it's impact is geometric, and thus paramount. However, the promises of technology will always fall short without proper vision and planning (architecture). If a business fails to see this, they will, in this information age, cease to be a business. The sooner a business can come to the realization that it must model itself and begin to holistically plan; the more competitive advantage it will have. This is a simple issue of pay now or pay later (if your business is around later). The longer you wait to get involved in enterprise architecture, the more it will “cost” when you finally do.
Enterprise modeling
The purpose of modeling your enterprise is to gain an understanding of the current state of the enterprise. Once the current state is understood, target states (strategies) can be derived. Models/enterprise artifacts are the requisite tools for success.
Enterprise models need to be multi-dimensional. They need answer a number of basic yet important questions in relation, and in parallel with other simular questions. These questions are the kinds of questions you learned about in grade school: Who, What, Where, When, Why, How. All of them; so simple, yet we often fail to ask them in conjunction with each other (let alone capture them in a model).
There are many approaches to the creation of enterprise artifacts, but no standards. Some of the approaches (e.g. Zachman Framework) are more comprehensive then others. Be as comprehensive as possible, stay relevant.
Who should be involved in EA
While EA movements often have their origin in IT departments, IT is not the place where EA should take place. This is largely because technology is implementation and has nothing to do with actual EA. Enterprise architecture is a business concern and should be carried out by business folks (enterprise architects). Enterprise architecture has a cultural impact and it should. EA is of a scope and nature that has a profound impact on the strategic maneuvers of an organization and thus has implications in terms of the distribution of "power" within an organization. Enterprise architecture efforts need to have a vast amount of visibility into an organization and should be solidly vetted by top level management. Changes to the system(s) [the enterprise] should go through, and be granted permits by the EA staff.
That being said, technology is the implementation, and there is no getting around the fact that technology is a major player. IT should have a representative on the EA steering committee.
Enterprise Architects
Enterprise architects are responsible to facilitate the creation of enterprise models. The work of the EA architect at the highest level is purely conceptual and model based. This is a space is a completely solution agnostic domain. In the information age the best candidates for architects are multi disciplined (Business domain / IT Architect) professionals. In reality enterprise
architecture is a cultural animal. Architects and EA related staff are
not the wielders of a silver bullet gun, but coaches; empowered
to help further a culture that has profound, positive impact on an
organizations ability to operate strategically. The enterprise
represents all that it effects, and all should be involved [EA as a soft skill].
One level down involves high level solution archetypes. Solutions remain agnostic to implementation but are defined as high level solution strategies. Assuming that systems will generally be implemented with technology, IT architects play heavily in this space.
- High level application approach
References
John Zachman – ZIFA (Zachman Institute for Framework Advancement)
Naor Pinto and Jim Bowen - for their feedback and consideration
