NULL
If you are reading this article, I probably don't have to convince you of the importance of developing and implementing enterprise architecture. Here is our definition of enterprise architecture: The set of plans that describes how all parts of the IT infrastructure need to behave to support the enterprise needs and goals. This includes all the data required to run the enterprise and the functions, technology and people that create, access, use or transform that data into information and ultimately, knowledge for the enterprise. By enterprise, we mean: All parts of the company, business unit, agency or organization for which you are creating an IT plan. If I needed to persuade you that architecture is critical, I would confess that I have seen-and been part of-many organizations that fail to plan. They may believe it is too time-consuming or too expensive to undertake architecture. But the results of proceeding with large, complex and often mission-critical IT initiatives without prior planning often lead to disastrous outcomes. Here are a couple of examples of what really happens when there is little or no IT planning, poor IT planning or with non-integrated IT planning:
- A four-year operational scheduling project did not make it into production because the technology plan was never integrated with the business and architecture plans. The result: By the time the technology was fixed, the business function is drastically downsized and the new application is overkill.
- A five-year critical enterprise database project was still struggling for acceptance, because project leadership focused almost entirely on new technology rather than trying to satisfy urgent business needs. The result: Funding is cut.
You may have experienced similar situations, for example when a Customer Relationship Management, ERP, or Enterprise Portal was implemented, without the benefit of an overall IT plan. 
On the other hand, in an earlier life, my architecture team and I spent one year creating the enterprise architecture for a very large, complex business. We developed and used a framework. We were rigorous in unearthing every problem. (Significantly, our "business input" came from IT.) We were relentless in creating solutions. Were we praised, applauded, received like royalty? We were not! We put together so much information, for so much of the business, that our officers were frustrated, overwhelmed and even threatened. It must have seemed to them as if we thought there was nothing they had done right! In retrospect, we were probably lucky to keep our jobs. So is there any happy medium between no architecture and too much architecture? I believe there is.
What is "Good Enough?"
The scenarios above both highlight common mistakes and reinforce the need for an IT planning methodology that works. Necessity being the mother of invention, I was forced to invent one. It was driven by my belief that the purpose of enterprise architecture is to align the IT infrastructure with the organization, in a way that best promotes the organization's goals, while maximizing the benefit of IT dollars spent, in the simplest possible way. I think this applies to many organizations investing in IT. For us, there were no architecture "cookbooks", but rather, trial and error, skilled and talented people and challenging assignments that brought about this birth. I would like to call our approach "Five Easy Steps to Architecture Success" but since I am (basically) truthful, our approach is really more simple and necessary than it is easy. What we call "good enough" architecture is based on lessons we have learned working with large, complex organizations.
Many fine minds have addressed architecture theory from the podium and the bookshelf. The purpose of this article is to help architects, IT planners and analysts find ways to implement those theories realistically, and to spare you as much pain as possible in the process. While you could spend a career-possibly a lifetime-getting your architecture perfect, we believe that focusing on a few key sets of decisions can result in the outputs you need, when you need them, at a relatively low cost and high quality/benefit. Our approach to architecture is very practical-it fosters rigor by focusing on outputs, but allows you to meet the business challenges of tight timeframes, resource constraints and on-going course corrections by choosing your battles. While we have a full-blown architecture development methodology, at its core, our "good enough" architecture is characterized by five principles:
- Keep it simple;
- Make sure you have business involvement;
- Use structure;
- Standardize outputs;
- The architecture is not "done" until the supporting infrastructure is in place.
Good Enough Architecture Principle #1: Keep It Simple
Keeping it simple means limiting the number and type of enterprise architecture outputs you develop and use. It means employing a simplified set of methods for constructing the outputs and delivering them within the real-life constraints of time and money. It means choosing a few areas of focus to deliver high value in an environment of non-stop change. The tension between the business realities and the desire to do a perfect job can be unbearable. Since the business constraints are a given, it is truly necessary to find a way to deliver "good enough" architecture. This means, essentially, making decisions to limit both the scope of architecture and the number of outputs created. This principle can be re-stated as "focus on a few." The acid test for simplicity is the time it takes to create the architecture. When you are keeping it simple, you should have quality outputs in weeks or months, not years!
Good Enough Architecture Principle #2: Get Business Involvement
When IT planners evaluate what is really necessary to create an IT plan and consider why it is such an important undertaking, the most important question that has to be answered is: "What will it take from IT to get the business where it wants to go?" In my experience, the two "cardinal sins" of architecture are an overly complex, techno-centric view of the world and a lack of clear business focus. As the earlier examples illustrate, IT projects that begin without a genuine understanding of the business needs and without business involvement often fail. Doing a high-level, up-front review of where the business is now and where it wants to be in the future is so critical that we use a framework specifically designed for collecting and analyzing key enterprise business information. How will you create a roadmap for collecting and analyzing key knowledge about the enterprise that will drive architecture? You will need to decide what business input you need, what are the best sources of information, and how you will organize the resulting data. To get started, here are some key questions to answer:
- What documentation exists that describes where the business is today?
- Who or what can provide a clear understanding of where the business is going?
- What are the significant gaps?
- What are the business solutions?
- What are the critical issues, areas of conflict and risk?
- Who can provide the most credible answers to these questions?
If you collect and use this information to drive your IT plan, you will ensure your architecture addresses basic business concerns. Perhaps as important, the set of business drivers you extract establishes the common basis for an IT plan that is integrated.
Good Enough Architecture Principle # 3: Use Structure
What kind of structures can help you define and organize outputs? We use frameworks for structure. To us, architecture frameworks are structures which define the scope, the set of outputs and the methods to create the outputs for enterprise architecture. We use three frameworks, but what is most important relative to frameworks is the issue of the scope of the architecture. In our scope, we include: Business Input: Our Business Framework provides a roadmap for collecting and analyzing key knowledge about the enterprise that will drive architecture. · IT Infrastructure: Our IT (Architecture) Framework provides a roadmap for creating the limited set of architecture outputs that will enable business goals. · Implementation Plans: Finally, we include a set of implementation strategies in our scope. These include best practices for addressing key areas that enable the actualization of the architecture.
Good Enough Architecture Principles # 4: Define a Few, Standard Architecture Outputs
How will you create a roadmap for developing the outputs of IT architecture that will enable business goals? First, you will need to decide what outputs you will create. In most cases, the outputs we include are Principles, Models, Inventory and Standards. Then you need to decide for which key infrastructure components you will create these outputs. We tend to focus on: Data/information; Processes/application functions; Technology (including networks)/services. The goal in good enough architecture is to create a limited set of architecture outputs that covers key business needs in the most simple, effective ways. Before you begin, it is also important to agree on how you will develop the outputs you selected. Here are some decisions you need to address to formulate your "how;"
- What will you include in the scope of your architecture? How are the outputs defined? How are they represented?
- How much detail do you need to include to clearly articulate architecture decisions and direction?
- What is your planning horizon? Next year? Two Years? Five years?
- What environments are you planning for? E.g., Run-the-business? IT Operations?
Putting in place methods that answer these questions will allow you to avoid becoming mired in conflict along the way, provide you with guideposts for measuring the quality of outputs and facilitate relatively quick construction of your architecture.
Good Enough Architecture Principle # 5: Set Up Supporting Infrastructure
To create and implement a truly achievable plan for IT, the architecture needs to address everything from the key business drivers through overcoming likely resistance. So our fifth principle directs you to create a set of implementation plans. These should include the key areas that enable the actualization of the architecture. Again, we believe this final piece to be so important that we have a third framework for implementation strategies. Here are some critical considerations you will want to address when you create a roadmap for implementation:
- A key set of business-oriented projects
- The development of metrics
- The packaging or marketing of architecture
- Processes and policies that support the architecture and the architects.
The architecture is truly complete when all the supporting processes and plans are in place. We have learned (the hard way!) that unless the enterprise architecture includes action plans and implementation activities, even the best architecture may never begin to be realized. Other Critical Success Factors While I would like to make a statement to the contrary, architecture is not a silver bullet. However, large, complex IT implementations stand a much better chance for success when they are based on well-thought out IT plans. Following these principles will help you develop that plan. And, finally, to achieve success, it doesn't hurt to have boundless enthusiasm and remarkable perseverance-these may be the most critical success factors for an architect! I once had a boss who wrote on my performance appraisal: "She got X, Y and Z done AND she is very stubborn" this is the kind of perseverance I mean!
Jane A. Carbone,
Partner, Infomajic