Whatever the nature of your business, one thing is certain: It's affected by change. Change is the one underlying constant that has an impact on every organization, regardless of its objectives. How well you manage change can make or break your business. No department in your organization is more affected by change than Information Technology (IT). And it's not uncommon to find an organization rely on IT to operate, where that department is totally reactive. In such a situation, the business is completely devoid of agility -- unable to adapt to the fluctuations of the world in which it operates. It is amazing that more of these businesses don’t immediately flounder, yet we run into this type of business again and again. Fortunately, we also run into the other type of business -- organizations in which IT is proactive and able to meet the demanding needs of change. What makes these organizations successful where others aren't? How do they do it? What makes them different from the "crash and burn" IT shops?
It's primarily their ability to manage change. But, to do that, organizations must be properly armed -- armed with the knowledge of who they are, what they do, why they do it, how they do it, where they do it, and when it's time to make their move. That's right: Organizations must fully understand the business they're in if they want to be able to compete, especially if they rely on IT to be contenders in their market space.
Nowhere is change more prevalent than in IT. Here, everything changes all the time. There are always new versions of products; there are always new deployments to be performed. Those of us in the Microsoft world have lived through DOS, Microsoft® Windows® 3.x, Windows 95, Windows 98, Windows NT®, Windows 2000, Windows XP, and -- soon -- Windows Vista®.
The rate of change in IT is increasing, as well. In the first iterations of the Windows operating system, the concept of a service pack didn't even exist. As the operating system evolved, not only were service packs introduced, but more and more updates were supplied in the form of hot fixes and patches. Windows NT sported six service packs; later versions of the operating system have fewer service packs but many more updates than previous versions, as shown in Figure 1). In other words, if you're an IT professional, you must manage change if you are to survive it.
Figure 1. The evolving rate of change in the Windows operating system
The emotional cycles of change
Working with change isn't easy. Everyone has some degree of difficulty in facing change, because change is often related to a period of mourning -- be it loss, negotiations in a given situation, or the need to adapt or accept a new situation. The first reaction is emotional: "Once again, we must live another change!" If you're the one initiating the change, this emotional cycle is simple and easy. However, if you're the object of a change -- that is, the one destined to receive the "benefits" of change -- you have an immediate reaction to it: resistance. Why? When you're the object of change, you don't expect it.
Reactions to change are often unconscious, but they consist of three basic elements. First is the cognitive element, which refers to the ideas and beliefs that apply to your role or your sense of belonging to the group or the situation in which the change applies. Second is the emotive element -- the emotions you feel toward the loss of your sense of belonging. Third is the behavioral element: How will you react when faced with this change?
Depending on the scope of the change, you're faced with what seems to be an attack on several of the elements that form your basic needs:
- The obsolescence of knowledge: "Must I relearn everything again?"
- The distortions your perception of the situation brings: "Did he say what I think he said?"
- Your previous experience with changes of this type: "Do you remember the last time they did this?"
- The basic fear of the unknown: "How will this affect me?"
These factors form the core of resistance to change. Change won't be accepted until a good deal of effort has been expended on information. What's worse is that until these efforts have been expended, people who resist change will expend effort of their own in its resistance. They will bring to bear their influence in the organization -- the more important their role in the organization, the more resistance they will apply. Figure 2 illustrates the emotional cycle of change and displays the difference between welcome and unwelcome change.
Figure 2. The emotional cycles of change
Whether you like it or not, you always face its emotional cycle. Think about it. Your own experience with change will teach you that this is the case. So what can you do to simplify change?
Use a change-management process
Completely eliminating the impacts of change is impossible, but you can at least try to alleviate them by introducing an element of stability. The only way to achieve stability within change is to develop a series of structured processes that you can apply to change situations. Resolutions Enterprises uses a five-step change-management approach called the QUOTE™ System:
- Question: The diagnostics or discovery phase. Here, you identify several factors in the change situation -- its origins, its scope, its objective, its impact on existing systems. To be able to do this, you must know what you already have.
- Understand: The planning phase. Now that you have information about the change in hand, you can start planning how you can influence that change. If the change is technological in nature, it's imperative that you fully understand how new technologies or new features affect the elements in place within the organization. This is a good time to perform a proof of concept.
- Organize: The first part of the execution phase. This phase focuses on testing and piloting the elements of the solution you identified in the planning phase. Because IT change tends to affect large sections of the organization (if not the entire organization), it's essential to validate all aspects of the solution before its implementation.
- Transfer: The second part of the execution phase. Now that your solution has been tested and modified according to test results, you can transfer the solution to all the sections of the organization that are affected.
- Evaluate: Finally, you must evaluate the change you implemented to best view how it can continue to evolve within your organization. This is the time to validate all the support methods you have put in place to ensure that they provide the structure required to allow further system evolution. The main objective of this phase is to ensure that the change is fully accepted and to validate that you are ready for further changes.
This description of a complex process is simplistic, but it does provide the beginnings of a framework for managing change. Figure 3 illustrates the cyclical nature of the QUOTE System. One core thread embedded throughout this system is communication -- constant communication at all levels and for every aspect of the change. People need to be informed of what's going on if you don't want to catch them unawares.
Figure 3. The five phases of the QUOTE System
Build the business architecture
So, how does all this affect the creation of a business architecture? As you can see, you must start at the beginning with a Question phase. In this phase, you can begin to answer the five Ws of your architecture: who, what, where, when, why, and (to add a sixth) how. We recommend using a structure that includes at least these 10 elements:
- Vision statement
- Goals and strategies of the architecture
- Driving principles for the architecture
- Geographic distribution of the architecture
- Principle actors in the architecture
- Information sources for the architecture
- Information flows for the architecture
- Architecture policies
- Architectural standards
- Implementation plans
The first three items -- vision, goals, and principles -- form the strategic plan of the architecture. Visions outline in a few words how this strategic plan will be achieved. They must include several key components, including a statement about:
- Customers that includes clients and key stakeholders, such as shareholders
- Organization itself and its well-being
- Cost control and profit generation, if they apply
- Growth and future opportunities
The vision is probably the most important aspect of the architecture. It must be realistic, simple to understand, and achievable. If you plan to go to the Olympics as an athlete, you probably have a vision of how well you'll succeed. If not, you shouldn't even bother packing. Visions don't have to explicitly include the components listed above. For example, John F. Kennedy had a simple vision for the National Aeronautics and Space Administration (NASA): "By the end of the decade, we will put a man on the moon." This vision, which addresses the what of the architecture, infers the customer, the organization, and cost control but clearly states the growth and future opportunities elements. Use this statement to guide the way you craft your business architecture vision.
The goals and strategies for the architecture must address the why of the architecture. Here, spell out the components of the vision more clearly. Basically, these components should outline the objectives of the organization. In addition, they should address goals not only for the organization but also for employees as individuals. Keep these statements short and simple to ensure that they'll be read and adhered to. Also, keep them limited to a realistic number. Too many goals hinders instead of helps their realization.
The third element that makes up the strategic plan is the set of principles by which you want to do business. Competition, by its very nature, gets you to strive to be the best. However, given the right principles, competition also make you a better corporate citizen. Once again, principles should be direct and to the point. They should state how you want your business to run. These principles can include statements such as:
- Use a win-win-win approach.
- Implement complete and interactive communications processes at all levels of the organization.
- Form a specific service contract between the organization and its customers.
- Define and publish a common vocabulary for the business.
- Unify all acquisitions for the organization to use a single, integrated process.
- Be prepared and watch for evolution points in the business.
These examples are not exhaustive, and you must flesh them out in your architecture to make sure everyone has the same understanding of each principle.
The where of the architecture is the geographic scope of the organization. Scope includes both the location of offices and the zones of influence your organization has among its customers. For example, one organization may have offices in a single location but zones of influence that span the entire world. This distribution is important for the business architecture. For the other architectures, the most important aspect of this scope is the location of its offices.
For the architecture's who, you have the principal actors in the architecture, including the organizational structure -- its hierarchy and its key stakeholders as well as the targets of the architecture or of the service delivery you are involved with. This element should also include partners and suppliers and their relationship to your organization.
Next, you must identify the information sources for the architecture. Designing a business architecture relies on a detailed inventory of what you have, where you want to go, and how you want to get there, so make sure that the sources of the information you gleaned are clearly indicated in the architecture. In this way, you can always go back to verify the source should any key element of the business change. In addition, be ready to add new sources of information as your business evolves.
Now, identify the information flows within your organization. Information flows from clients to you, from you to clients, from you to suppliers and partners, and back. Identify and prioritize these flows as much as possible so that you can identify the interaction points between your organization and all the players that interact within and without it.
With respect to architecture policies and architecture standards, in the case of business, these are the policies that make the business run and that form the policing fundamentals around business processes. Standards can be drawn from the industry in which you operate and can be supplemented by your own experience.
Finally, implementation plans form the when of the architecture by outlining how you plan to move from your current state to your new, architected state. In the case of a business architecture, this move is oriented more toward communications and understanding than actual modification of the way things are done. This is not to say that you won't discover opportunities for change during the elaboration of this architecture; but in most cases, people know how to run their business before they embark on this process. In contrast, the business architecture proves fundamental for all other architectures that make up the enterprise architecture.
Summary: You are what you know
It is difficult to provide concrete examples of business architectures because of the nature of business: Some operate for profit and some don't, some operate purely as services to others and some as primary product providers. However, these guidelines will at least assist you in its preparation. As we move through the other architectural aspects of the enterprise architecture, it will be easier to give more concrete examples.
For now, know that designing an architecture relies heavily on proper inventories. You are what you know. And when you know as much as possible about your business, you can control it, mold it, and maneuver it to your heart's content. Along the way, make sure you address the fears you know everyone will face as change arrives -- they'll be grateful for it. Also, rely on the QUOTE System, because building an architecture really runs through each phase of the system, beginning with discovery and moving through each phase as you implement the architecture.
Learn
-
Stay current with
developerWorks technical events and webcasts.
-
The QUOTE System was first presented in Preparing for .NET
Enterprise Technologies, by Danielle Ruest and Nelson Ruest (Addison Wesley, 2002).
Get products and technologies
-
Build your next development project with
IBM® trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Participate in developerWorks blogs and get involved in the
developerWorks community.
Danielle Ruest is a senior enterprise IT architect (EITA) focused on people and organizational issues for large IT projects. Danielle has been involved in the design and support of complex collaboration implementations, including deployment of technologies for e-mail, team sharing, and secure instant messaging. With her partner Nelson Ruest, she is the author of Preparing for .NET Enterprise Technologies, (Addison Wesley, 2001). and Windows Server 2003: Best Practices for Enterprise Deployments (McGraw-Hill Osborne, 2003) and participates in many webcasts and conferences. You can reach Danielle at architectures@reso-net.com
Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network, computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at architectures@reso-net.com.
