Michael Rosen
May 2007
Summary: Understand the architecturally significant aspects of business analysis on which a project architect should focus. (6 printed pages)
Contents
Introduction
Northwinds Trading Gets a Business Model
What Is Business Analysis?
Review
Critical-Thinking Questions
Sources
Glossary
Introduction
Imagine yourself on an assignment at Northwinds, an options-trading company. They have brought in your team to help upgrade the critical applications used day in and day out by the traders. As new kinds of options and other financial instruments are created, the old, inflexible applications are breaking under the pressure for change and integration. Today is an important day, and your trepidation peaks as you pull into an empty spot in the parking lot. As you look around, you notice that your car is the cheapest vehicle in the lot, which is dominated by BMWs, Porches, Jaguars, and the occasional Bentley. These guys make a lot of money, and they don't have a lot of time or patience for "theory," "architecture," or excuses.
Still, you know that, to meet the new regulatory and conformance requirements, and to achieve the goals of common processing and reporting, you will need to have both a business model and a technical architecture.
The
business model defines the processes and entities of the business, and identifies what must be common to meet the new system requirements. The
technical architecture will define patterns for implementing the business on a common technology platform. It will have to support the business architecture; but, on the Northwind project, the business model—not technology—is your focus and responsibility.
Northwinds Trading Gets a Business Model
Today is the day of the first "business-modeling" session. It will be attended by the IT group's business analysts, as well as by a few senior traders forced to attend. You kick off the meeting with an overview of the goals and a brief introduction to what a business model will look like. A prepared poster on the wall acts as a key to three concepts that will be used in the exercise; and, quickly—before any eyes can glaze over—you jump right into creating the first model on the whiteboard.
At first, the model seems to be obvious and simple, as you illustrate the basic modeling concepts. But, based on upfront preparation, you start to dig into the details with some careful prodding and questioning. Pretty soon, you hit pay dirt. Two of the senior traders are arguing over what something means or the way it works. As you facilitate a discussion to get to a common understanding, you model the solution on the whiteboard—essentially, documenting the agreement. When the main details are worked out, it's time for a coffee break and to reiterate what has been accomplished over some casual conversation. After the session, you transcribe the whiteboard contents into formal models in an appropriate tool.
So, what has been accomplished? It's much more important than the simple start of a business model. You have demonstrated two critical values of the business models themselves. First, you have exposed the fact that, although the experienced and senior people might have thought they knew how things worked, at best, they discovered that they had differing conceptions. Secondly, you have shown how a simple and easy-to-understand—but formal—model can document the business unambiguously.
Over the next few weeks, the modeling sessions increase to two mornings a week, in order to meet the deadline and expanded scope. Before each meeting, you publish the models from the previous meeting. Over time, you introduce two or three more important model concepts (with updated posters). Another interesting thing happens. More senior traders begin to participate—both to learn and to make sure that their understanding of the business gets represented in the model. People who make $500,000+ per year and have no patience for technology are willingly attending your business analysis and modeling sessions!
Fantasy? Other than the fictitious name, this is exactly what happened on my project with an options-trading company. The activity not only produced definitive models of their business, but it also provided the project team with the information and process models they needed to understand the requirements for this and future projects and optimize their implementations.
How did we make that happen?
- Well, first, never assume that business people are stupid or too dumb to understand. Financial options are among the most complicated things I've ever worked on. Those traders were really smart; they just didn't care about the technical details.
- Keep models simple, by limiting the concepts to a very few. We represented the business concepts and entities in pared-down UML class diagrams using only specialization, composition, and dependency relationships. [ISO/IEC 1996]
- Start small. Demonstrate value, and build from there. This cannot be stressed enough. You must demonstrate value—for example, by showing how the modeling activity can expose and resolve differences in understanding of the business.
- Focus on the important things. Any of you who have teenage children understand the wisdom of the saying, "Pick your battles." Architecture is no different. An architect must focus on the aspects of the business that need to be common. Do not try to create an enterprise definition of everything. I cannot think of a single enterprise-wide data-dictionary–type of project that ever worked. Instead, identify the subset needed to support the enterprise business requirements, focus on them, and forget about the rest. At Northwinds, we identified only what needed to be common to support regulatory compliance and some specific application-integration scenarios.
- Know your audience. Talk business to the business people and technology to the IT people. In our business-modeling sessions, we never once discussed how the concepts would be implemented or what technologies, platforms, or systems would be used. But, if you are going to have any credibility, you sure as heck had better be able to talk about those things to the project team.
What Is Business Analysis?
So, what is
business analysis (BA), and how does it relate to the job of an architect? According to the International Institute of Business Analysis [IIBA 2006]: "A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals."
In other words, the business analyst acts as a bridge to convey requirements between the business customers and the project-development team. However, the architect is not the same as the business analyst. The architect has a different set of goals and responsibilities. Architecture is not about building a single application, but instead about establishing commonality, such as technology platforms, business entities (like customer), and business processes (like compliance) across multiple applications that are part of a bigger picture. Like the business analyst, the architect acts as a bridge to the individual projects. Those who are tasked with an individual project cannot be expected to know or care about the bigger picture. Instead, the architect has to help the project team and business analyst incorporate the big picture into the current project-analysis activities.
Wikipedia [WIKI 2006] has this to say: "Business analysis, as a discipline, has a heavy overlap with requirements analysis, but focuses on identifying requirements in the context of helping organizations to achieve strategic goals...".
While both BA and architecture are about achieving strategic goals, BA is more focused on the identification and specification of requirements within that strategic context, while architecture is more focused on identifying and specifying those things that must be common across applications to achieve the business and enterprise goals. Obviously, there is overlap, and architecture must work closely with BA in integrating the enterprise requirements into its understanding of the business as a whole. This will call on the architect's ability to talk about technology concerns in a business context.
The business analyst and architect also intersect in the areas of analysis, documentation, and communication of the requirements. Here, architects can bring their analytical skills to bear in applying
separation of concerns,
abstraction, and identification of roles and responsibilities to create formal, unambiguous, and implementable models of the requirements.
A business analyst is responsible for creating a business model that conveys the business requirements. Unfortunately, there is not really a universal definition of what a business model is. Some business models include goals, organization, key performance indicators, and other high-level concepts. Other models include value chains and business-context diagrams. Yet others contain use-case, business-process, and business-entity or information models. The higher-level models are important for setting the overall enterprise context and are often created by business architects, while business analysis is more project-focused and often produces the last set of models mentioned earlier. We sometimes call this set of artifacts a
domain model. For example, the Rational Unified Process [RUP 2001] states: "A domain model provides 'the big picture' of a complex organization. It shows the major business entities, their functional responsibilities, and the relationships among the entities."
The architect has two important contributions to the business or domain model. First, the architect acts as a bridge between the enterprise requirements and the project-specific business requirements. Secondly, they formalize requirements into business models. The exact format of the business model is less important than what it achieves: the specification of business and enterprise requirements, independent of implementation technologies. The attributes that make for good requirements [McEwan 2004] apply also to good business models. Some important attributes of a good business model are that they are:
- Unambiguous. If anything can be interpreted in more than one way, it will be—resulting in inconsistent behavior and information.
- Complete. The model must specify the business rules, processes, and information required to build the system. The architect must ensure that this includes everything that needs to be common across applications. However, do not confuse completeness for detail. The model should contain business information, not implementation detail.
- Consistent. The business model must be consistent with both itself and the enterprise requirements. In addition, it must be kept up to date, as requirements evolve during project implementation.
- Traceable. Processes and entities in the business model should be traceable back to requirements.
- Agnostic. The business model is a statement about the business and specifies what will be implemented. The solution model is a statement about the system and specifies how it will be implemented. You must maintain this important separation of concerns.
The models that we created at Northwinds provided an unambiguous definition of the options-trading business at that company. They were complete in specifying all of the information that needed to be identified and shared to meet the business and enterprise requirements, but they were not overly detailed. We assured consistency and traceability through our analysis process that produced the models and kept them free of implementation detail. Then, we worked with the development team to help them use the models in their development activities.
Although the underlying technologies and applications have changed several times since the original project six years ago, the business models are still in use today and are still providing value. Our team of architects and business analysts worked together with the customer's subject-matter experts to produce the models. The business analysts provided the business knowledge and primary interface with the customer, and the architects provided the critical-thinking and formal-modeling skills necessary to produce the models and to interpret them for implementation across multiple projects. Never forget that an architect's job is not to create architecture, but instead to help development use the architecture to create better applications that fit within a larger context.
Review
Business analysis is the elicitation, collection, and specification of requirements. It is a critical component of the success of any project. Although the business analysts should be putting those requirements into a strategic context, their primary responsibility is for the project. The architect, on the other hand, is responsible for thinking across projects and interjecting enterprise requirements into the business-analysis activities—that is, acting as a bridge between enterprise and project concerns. In addition, an architect can help to better express requirements, in terms of formal models that can be unambiguously implemented by the project-development team.
Critical-Thinking Questions
When involved in business analysis and development of a business model, the architect should keep a few critical questions in mind.
- What information or processes must be specified to meet the cross-application requirements? How is it reflected in the model?
- What is the minimum amount of information necessary to convey the requirements? Does the model specify enough? Are all business rules, shared information, and common processes identified? Does the model try to specify too much?
- Does the model separate business from technology concerns? Is it simple enough to be understood by the business subject experts?
- Is the model internally consistent? Does it provide a consistent level of abstraction and detail? Is it the right level?
- How will the business model provide value to the project and the development team? Can it be implemented? Is the prioritization of activities correct?
Sources
Glossary
Abstraction—Generalization of content and/or suppression of unrelated detail to allow for a broader view, reduce complexity, or focus on a specific viewpoint.
Business analysis—Elicitation, collection, and specification of requirements to meet business, project, and strategic goals.
Business model—Defines the processes and entities of the business, and identifies what must be common to meet the new system requirements.
Domain model—Provides "the big picture" of a complex organization. Shows the major business entities, their functional responsibilities, and the relationships among the entities.
Separation of concerns—One of the most fundamental principles of architecture. Identifying and keeping independent things uncoupled and independent, so that changes in one do not affect the other adversely.
About the author
Mike Rosen has 25 years of software experience as a developer, product architect, application architect, and enterprise architect. He is a practicing architecture consultant, speaker, and author, as well as Director of Enterprise Architecture for the Cutter Consortium and Co-chair and Editorial Director of SOA Institute.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.
