Developing an Enterprise Architecture

Even with the MSF model at our disposal, we’re still lacking an important ingredient before we can jump into software design. We are lacking the proper context in which the software we are going to create exists. We are lacking an understanding of how the organization views technology and how technology is currently being used. We are lacking an understanding of the enterprise architecture.

Enterprise architecture (EA) means different things to different people—it really depends on who you ask. Some might say it’s a business document that describes the nature of a business and its relationship with itself, its customers, and its vendors. Others might portray it as more of a technical document describing the systems and applications used inside an organization and explaining how data travels from one system to another. In reality, both views are correct. The EA document, also called an EA model, should contain both a business view of an enterprise and a technology view of an enterprise. The purpose of creating an EA model is to align these two views.

The first step when creating an EA model is to define the current business and technical architecture. This is called the baseline, and it serves as a way to document the way things actually operate within a business. Creating even this baseline model can be a bit of a challenge, as it involves an honest assessment of the way things really are—no matter how improper or dysfunctional it may seem.

The next step in creating an EA model is to perform an analysis of the baseline model to identify any improvements that can be made in the business or technical architecture. This can be the toughest step of the entire process because it requires you to put aside personal biases and not worry about the political implications of certain changes. Some processes are unnecessarily complex and need to be simplified. By all means, simplify!

The third step is to take this analysis of the baseline and use it to design a future architecture model to which the enterprise can slowly transition. This is called the target architecture, and it aims to solve many of the process problems identified during the analysis stage. The target architecture should answer the question, “How will this organization look in five years?” Of course, the target environment might be radically different from one defined in the baseline unless you’re lucky or just happen to be in a slow-growth industry, in which case the two models may be very similar.

The final step is to identify how the organization will be transformed from the baseline to the target architecture. What changes will be implemented? How quickly will the corporate structure be reformed to meet the challenges of the future business environment? Crafting this transformation is a delicate process because these changes will undoubtedly affect the day-to-day lives of some of the employees of a company. If departments are merged, will there be layoffs? If technology is shifted, what type of training will be provided? A target architecture that is well thought out is very useful, but one that is not can cause more problems than it solves. As someone once said, “if you fail to plan, you plan to fail.”

Enterprise architecture plays a key role in application development because it is important to understand how the solution concept, which we will learn about later in this chapter, fits in to the “big picture.” If the organization is moving toward one technology standard, such as XML web services, that should be taken into consideration when designing the solution.

Defining the Baseline Architecture

The baseline architecture is the definition of the current architecture of an organization. This model contains both a business and a technical view of the company. The business view describes the operational elements of an organization and how they interrelate. Someone should be able to read the business view section of the baseline architecture and completely understand how an organization operates.

The technical view describes the computer systems and applications within an organization and how they interrelate. There will be some overlap (hopefully) between the business and technical views in that the elements of the organization that interact on an operational level (customers, salespeople, orders, invoices, and so on) should also have some relationship at the technical level.

Defining the Business View

In a large company, you are unlikely to find a single person that understands both the business and technical architectures to such a degree that you can construct the entire EA model based solely on their knowledge. This means that you will need to work with people from almost all departments within the company. Only someone from the sales department can accurately explain how people in the sales department interact with people and systems inside and outside the company. Likewise, only the accounting department will be able to explain things from the point of view of the accounting department. It is the collection of all these points of view that goes into building the business model of the enterprise.

The business view of the EA model should take into consideration the following list of operational elements:

• People The human resources of an enterprise

• Strategy The enterprise vision and focus

• Functions The processes and tasks of day-to-day operations

• Information The knowledge and data that feeds the processes

• Infrastructure The equipment, machinery, and other IT resources that exist inside the organization

• Organizational structure The hierarchical and geographical structure of a company

These six elements are combined to define the overall structure of the enterprise. The purpose of creating the business view is to document these elements, including the relationships between them.

We can take advantage of a number of popular modeling methodologies when creating the EA model, including use case, activity, and state diagrams. These three diagrams are created using the Unified Modeling Language (UML), a popular methodology for designing object-oriented systems and applications. The interactions between components of an organization can be modeled graphically, similar to graphic modeling in an object-oriented application.

Exam Watch

UML is a graphical language for visualizing object-oriented systems. For more information, visit the official UML web site at http://www.uml.org.

Figure 2-1 shows an example of a UML state diagram. This state diagram reflects the changes of an object within the system over time. This example shows how the state of an order changes between the time that a warehouse receives it and the time that the order is shipped.

Figure 2-1: A UML state diagram can be used to define a business process.

Exercise 2-1: Create a UML State Diagram Using Visio for Enterprise Architects

A UML state diagram is a useful tool for describing the behavior of a system. Visio for Enterprise Architects makes it extremely simple to create a diagram that can be used inside an EA model. In this exercise, we will create a UML state diagram that models all of the valid states of a food order at a fast-food restaurant.

1. Choose Start | All Programs and choose Microsoft Visio to start the application.

2. Choose File | New | Software and select UML Model Diagram to create a blank UML model.

3. Choose UML Statechart from the list of templates on the left.

4. Drag the Initial State icon from the template onto the blank page and place it near the top of the page. The Initial State icon looks like a large dot.

5. To add the first state to the diagram, drag the State icon from the template onto the blank page just underneath the Initial State icon. The State icon looks like a rectangle with rounded corners.

6. Name this state “Awaiting Payment” by right-clicking on the State icon, selecting Properties, and typing Awaiting Payment in the Name field of the UML State Properties dialog box, as shown in the following illustration. Click OK when finished.

   

7. Using the same method, add two more states: “Paid” and “Completed.”

8. Drag the Transition arrow from the template onto the diagram, connecting the Initial State icon with the first state, Awaiting Payment.

9. Identify an action with this transition by right-clicking on the Transition icon and selecting Properties.

10. Choose the Actions category.

11. Select the New button and choose Create Action. Name this action Enter order, as shown in the following illustration.

    

12. Add transitions for the other states. Name them Accept payment and Deliver food.

13. Add a Final State icon to the diagram from the templates and place it underneath the three states. Connect it to the Completed state using a transition arrow. The Final State icon looks like a large dot with a circle around it.

14. The UML state diagram will look something like the illustration shown next:

    

Defining the Technical View

The technical model is, of course, a different story and needs to be treated separately from the business model. The technical processes might be in some ways easier to construct than the business processes, because the existence and structure of systems, networks, and applications are more absolute and usually better documented.

Typically, the EA technical view is subdivided into five smaller architectures:

• Infrastructure architecture Describes the physical network

• Information architecture (IA) Describes the information and data collected

• Enterprisewide technical architecture (EWTA) Describes the core systems and tools

• Application architecture Describes the software development approach

• Integration architecture Describes how new systems will integrate with existing ones

Figure 2-2 shows how the five architecture types fit within the EA model.

Figure 2-2: The enterprise technical architecture consists of five architecture types.

Infrastructure architecture is the network hardware and wiring that connects everything together. The big topics to consider are required capacity, security, and monitoring methods.

Information architecture (IA) is concerned with the data collected by an organization. The IA is usually examined from both a logical and a physical point of view. At the logical level, the IA documents the relationship between the various business entities involved, such as employees, customers, orders, and vendors. At a physical level, the IA documents what data is stored, where it is stored, and how applications within the organization access that data.

Enterprisewide technical architecture (EWTA) describes the set of technologies upon which third-party or custom-developed applications are built. These technologies include operating systems, programming languages, database systems, application servers, and web servers. EWTA also describes other tools used within the organization such as e-mail, reporting tools, and knowledge management.

Application architecture describes the approach a project should take when a company is developing new applications. For instance, this is where a company would choose the .NET platform as the corporate standard technology for creating new applications. The application architecture document can go even further and suggest a web services model or recommend continuing to develop applications in COM+ using the appropriate .NET wrappers, as discussed in the last chapter.

Integration architecture is the final piece of EA model. It describes how an organization will manage the transition from the current baseline architecture to the new target architecture. Are systems going to run in parallel, or will they be switched over to the new architecture all at once? Can some systems be transitioned seamlessly over to the new architecture without affecting any of the existing systems? The integration architecture should be able to answer that.

We have already said that, in some ways, the technical architecture will correlate well with the business architecture. This has to be true to some degree, or else the business wouldn’t be able to function at all. If there were no correlation, information from the order system would not make its way to the distribution systems for processing. The business-technical integration may not be ideal (the ideal scenario will be considered during the target architecture phase), but there has to be a fair bit of correlation already.

Scenario & Solution

Which EA component documents the LAN, WAN, and other corporate networks?	Infrastructure architecture
Which EA component documents the type of data collected by an organization?	Information architecture
Which EA component documents the technical approach that should be taken when designing a new application?	Application architecture
Which EA component documents how the organization will transition to the target architecture?	Integration architecture

Analyzing the Business Environment

Once the EA model is complete, it still may not be entirely clear what problems need solving within an organization. Things may seem to be working as they should, and you may be tempted to stop the process right there since nothing appears to need to be fixed.

Of course, questions still need to be asked about the existing business processes. Are the business processes unnecessarily complex? Are there tasks being performed manually that can be automated? Have we identified the processes in the organization that are not working effectively and efficiently, where the stated goal of the process is not really being achieved? It really does require an honest analysis, without regard to personalities or politics. Sure, you don’t want to offend the executives of your company (your ultimate bosses) by saying that senior managers are making decisions without having proper or timely access to information. However, if that is an area that needs improvement, it should be pointed out.

Besides an analysis of how things are (or are not) currently working, you also need to consider the future needs of the organization. What aspects of the industry you operate in are expected to change over the next few years? Are there any business avenues that aren’t being explored, and will the company be able to react when new opportunities do arise? The answers to all of these questions will help you understand some of the potential improvements that need to be made with the current architecture.

Aligning the Business and Technical Architectures

Once we have completed the analysis of the business view, we will need to analyze the current technical architecture of the organization. The chances are good that there are technical issues that will need fixing, as technology continues to change and improve over time. Perhaps there is too much variety in the hardware and software composition of the organization—a seemingly random mixture of server types, operating systems, networks, and application software—or perhaps the underlying systems are already struggling to meet the current needs of the business and will surely buckle under the weight of future needs.

The technical architecture needs to be able to support the stated business goals of the company. If the organization will double in size in five years, a plan needs to be designed today that will support that growth. If the organization will expand into new lines of business, its technical architecture must be flexible enough to support that expansion as well.

Once the analysis has been performed on the business and technical components of the architecture, it is time to create the target architecture. This part of the process is critical because you are articulating the future vision that was identified in the last two steps of the process.

Making a Commitment to Architecture

Spending a lot of time and money developing an EA model would be worthless if the business did not intend to follow it. The EA model is like a road map. It will show you where you are, where you want to be, and even how to get there.

Developing and sticking to EA model takes commitment from all levels of an organization—from the executive offices all the way down to the leaders of the smallest project teams. What makes the EA model so important is that it answers the question, “What can this company do to improve itself over the next few years?” If only the top executives of a company can answer that question, then everyone in the company may not be working together.

Of particular importance to software designers is the fact that the EA model has a direct impact on how software is designed within the organization. In fact, the EA model will define the playing field in which the designer and developers have to work. If the company plans to spend lots of time, energy, and money building a companywide .NET infrastructure, you will find it hard to suggest a Java 2 Platform, Enterprise Edition (J2EE) solution for a particular business problem. Likewise, if the company has invested heavily in making all its applications web based for cross-platform accessibility on the client side, you would need a really good reason to pursue a Windows-only application as a possible solution to another business problem.

It’s important to understand the enterprise architecture of the organization, at least in a general way, before embarking on developing solutions for business problems. Not very many companies take the time to create a proper plan such as this, although those companies usually provide a set of technical standards related to database management software, operating systems, and application server software to guide designers in their decision making.