Enterprise Architecture: Enterprise Unified Process
Table of Contents
- Overview
- Defining architectural requirements
- Defining candidate architectures
- Refining enterprise architectures
- Defining reference architectures
- Supporting project teams
- Summary
1. Overview of Enterprise Architecture
An effective enterprise architecture promotes consistency across your organization’s systems by guiding development teams towards using a common set of proven approaches to, and even product-lines of, application architecture. This enables both reuse and system integration through common mechanisms and compatible semantics across systems. Enterprise architects are concerned with how their work impacts multiple systems for both the present, in the form of “as is” models, and for the future, in the form of “to be” models. They look further than the needs of a single application and assess architectural impact on the entire enterprise, looking beyond the current information technology (IT) needs and laying the foundation for future efforts.
Enterprise architects are responsible for formulating, proving, and then supporting the enterprise architecture. The architecture itself is built out through the efforts of your enterprise administrators who are responsible for your data, security, network, and hardware infrastructures. Your enterprise architecture will also be built out by application project teams. Your enterprise architects should not only support these build out efforts they should also be actively involved in them.
The main difference between enterprise and application architecture is one of scope. Whereas an application architect on a development project identifies architectural solutions for a system, an enterprise architect defines architectural solutions, frameworks, patterns, and reference architectures for use across multiple systems within the organization. Application architects guide the team of application designers and implementers in their efforts of understanding and applying the application architecture; enterprise architects guide application architects in their understanding and applying of the enterprise architecture. Just as application architects take a broader yet generally shallower view than the designers and implementers of a system, enterprise architects take a broader and generally shallower view than application architects. Although the enterprise architect establishes the architecture for your organization, the actual implementation of it is done by your application development teams and by enterprise administrators (who often build infrastructure in advance of systems being released).
An important thing to note is that the EUP distinguishes between an Enterprise Business Modeling discipline and an Enterprise Architecture discipline. Some organizations choose to combine these two things into a single discipline, which is perfectly fine. Do the right thing for your environment. The high-level workflow for the Enterprise Architecture discipline is shown in Figure1 and the detailed amalgamated workflow in Figure 2. Enterprise architecture is not just about modeling the “big picture.” Models are an important part of enterprise architecture efforts because they help depict and convey the enterprise architecture, but it is more accurate to say that enterprise architecture is represented in the structure and distribution of technical and business assets of the enterprise. In short, an important message of this discipline is that in order for it to succeed your organization must be as agile as possible: it is possible for enterprise-level professionals to work in an agile manner, but they must choose to do so and be allowed to do so.
Figure 1. The Enterprise Architecture workflow.
Figure 2. The amalgamated workflow of the Enterprise Architecture discipline.
2. Enterprise Architecture: Defining Architectural Requirements
An architecture, be it an application architecture or your enterprise architecture, must reflect a set of requirements. Figure 3 depicts how to identify the technical and business requirements for your enterprise architecture. Some architects want to focus solely on technical issues, but my experience is that this isn’t sufficient. The primary goal of your enterprise architecture is to enable the business to meets its IT goals and objectives, not simply to define the “cool technologies” that the IT people get to work with. Hence you must identify both technical and business requirements.
Figure 3. Defining architecture requirements workflow details.
Your enterprise business model identifies the fundamental business aspects of your organization, including business processes, business rules, and domain entities. This model captures the high-level business requirements to which your enterprise architecture and the systems you develop should conform. Enterprise architects will use this information to ensure that IT solutions keep pace and support the changing business environment. The portfolio plan, produced as part of your portfolio management efforts, helps enterprise architects to understand the current and future direction of application efforts. The portfolio plan indicates the upcoming projects that are currently identified, as well as when they are expected to start. For example, if you see that more systems are planned for the long term that need historical data for decision support, you may decide to start investigating a data warehouse solution to lay the foundation for such efforts. You must also identify technical requirements, including those relating to performance or availability, which your enterprise architecture must also reflect.
3. Enterprise Architecture: Defining Candidate Architectures
When you are first formulating your enterprise architecture model, it isn’t reasonable to try to address all of these issues at once; instead you should tackle individual aspects of your enterprise architecture one at a time. This strategy is also appropriate for evolving your enterprise architecture: you want to do so gradually so that your organization can successfully adopt a new infrastructure in a low-risk manner. A good approach is to identify and then validate candidate architectures, which are the building blocks from which your enterprise architecture is built. In other words, be as agile as possible in your EA approach.
A candidate architecture is a proposed addition or change to the enterprise architecture that has not been fully detailed or implemented; it may be as nebulous as the statement “start exposing our applications to a wider audience of users, possibly via web services” or as concrete as the idea that you should adopt a persistence framework such as Hibernate. Candidate architectures can be described in various formats, from something as simple as a paragraph describing the idea to a simple position paper to a detailed white paper describing a new technology. Depending on the scope of the candidate architecture, you may need to investigate it further through online research, attendance at conferences or training sessions, online discussion groups, or by talking with your peers at other organizations that have experience in the technologies.
The next step is to show that the candidate architecture actually works and fits into your existing enterprise architecture. Of course every product works perfectly in marketing literature, but you don’t want to put your organization at risk by adopting a technological solution that you are not familiar with. Furthermore, technologies such as .NET and J2EE are complex beasts that cannot simply be deployed “out of the box” but instead must be adapted to each environment. Questions to address include: Which one(s) will work best for the enterprise now and in the future? How will applications built with .NET integrate with
legacy applications and data sources? How will .NET be deployed and supported? Which parts of .NET can applications use and which parts should be avoided? How will security be implemented in .NET? All of these issues, and more, need to be investigated and proven to work within your environment. It’s not enough to just say it will work; it must be demonstrated to work.
4. Enterprise Architecture: Refining Enterprise Architectures
With a suitable candidate architecture in hand, the enterprise architects integrate it into your enterprise architecture model, as depicted in Figure 4. Your enterprise architecture model should reflect accepted enterprise administration guidance, such as security and data standards and guidelines, which is maintained and supported by your enterprise administrators. It should
also reflect the modeling and enterprise development guidance that the enterprise architects develop and support for your organization. Your enterprise architecture is probably very complex, so you will need several views to adequately model, such as those promoted within the Zachman Framework.
Figure 3. Refining the enterprise architecture workflow details.
Your enterprise architecture model is an important artifact used by several of the other enterprise management disciplines.
Enterprise business modelers use it to help determine potential opportunities to automate portions of a business process, the end result being a new project proposal. Your enterprise architecture model is used in the Strategic Reuse discipline as an input into setting the vision of your organization’s reuse program. It is also used as an input into determining whether an existing asset should be generalized into a robust asset that could potentially be reused and to identify the criteria for assets that are to be developed or purchased. Because your model calls out technical issues such as your network architecture, your data architecture, and your security architecture, it is valuable information for your enterprise administrators who are responsible for building and then managing these portions of your IT infrastructure.
5. Enterprise Architecture: Defining Reference Architectures
A reference architecture is a working example designed and proven for use in a particular domain, together with supporting artifacts to enable their use; it at least serves as an example and at best provides the basis for creating an application architecture. Reference architectures help application teams to craft application architecture that utilize your enterprise architecture. They can greatly speed application development effort and minimize support costs because applications are architected in standard, proven ways. Reference architectures are not theoretical models of how things might work. They are proven patterns of how things do work. Nothing demonstrates that better than working code that teams can inspect to see how to apply it.
A reference architecture may be geared towards a particular technology or domain. The reference architecture should be documented in a manner that is easy to use by application developers. One way to do so is to create a standard RUP Software Architecture Document (SAD). Remember to keep your documentation concise and well written; it is possible to be agile when creating documents.
6. Enterprise Architecture: Supporting Development Teams
A vital part of the enterprise architecture discipline, as with the other enterprise management disciplines, is supporting software development teams. It does no good to define a great enterprise architecture if the teams cannot understand it or do not adhere to it. Enterprise architects must work with development teams to help them succeed at adopting and following the enterprise architecture.
Enterprise architects work closely with application architects (the software architect role in RUP) to help them formulate architectures for specific applications. They do this by helping them to apply reference architectures and to craft application architectures with enterprise needs in mind. A good enterprise architect will spend the majority of his or her time mentoring others. Enterprise architects will also hold training sessions. This may take the form of formal, classroom-style lectures, brownbag lunches, or presentations. Training is often called for when a significant change or addition to the enterprise
architecture is made that needs to be communicated to the entire IT organization. Enterprise architects can get the word out to the largest audience quickly by presenting some form of training followed up with mentoring to specific application teams or individuals.
The following advice, which I describe in detail in the book The Practical Guide to Enterprise Architecture and online in Agile Enterprise Architecture, will help enterprise architects to work effectively with project teams:
- Focus on people, not technology or techniques. The greatest architecture model in the world has little value if you can’t find a way to work with developers effectively and convince them to use it.
- Keep it simple. The simpler the architecture, the greater the chance that it will be understood and actually followed by developers.
- Work iteratively and incrementally. Your architecture will evolve over time due to new requirements, new technological choices, and greater understanding amongst your enterprise architecture team.
- Roll up your sleeves. Developers won’t respect you, and therefore won’t accept your architecture, if you aren’t willing to get actively involved in their project efforts.
- Build it before you talk about it. Everything works in diagrams but can fail miserably in practice. Just like in the RUP, you should prove your application architecture via technical prototyping; there is no reason why you can’t do the same at the enterprise level.
- Look at the whole picture. This is a primary skill of enterprise architects, which is one of the reasons why a multi-view approach is so important to you.
- Make architecture attractive to your customers. If your enterprise architecture artifacts aren’t easy to understand, to access, and to work with, your customers (developers and senior managers) will very likely ignore your work.
7. Summary
The Enterprise Architecture discipline defines the activities necessary to define the enterprise architecture for your organization. It describes the process to craft the enterprise architecture — the frameworks, networks, deployment configurations, domain product lines, and supporting infrastructure that form the architectural infrastructure for your organization. Enterprise architects will also supply reference architectures — an architectural pattern designed and proven for use within the enterprise architecture, and the technical requirements, standards, and guidelines that the enterprise architects set for applications to follow.