Requirements for Enterprise Architecture: First Look

Traditional requirements happen after a multi-system architecture has been defined.

But what about the requirements that feed into that architecture? The requirements that drive the enterprise architecture decisions in the first place? We haven’t talked about those before.

Setting The Stage

The typical enterprise software requirements project ecosystem looks something like the following:

1. An existing application exists within a network of (logically) interconnected applications that collectively comprise an enterprise architecture.
2. Business processes exist, each of which utilizes one or more of these applications to achieve tangible business objectives.
3. Some of these applications have user interfaces, and therefore have users who are trying to achieve the goals associated with the business processes.

Within that environment, the typical enterprise software requirements project looks very familiar:

1. There are new processes, or capabilities that are desired by the business.
2. An enterprise architect has decided that these capabilities will be embodied into one or more of the existing applications. The end result is that each application has a “defined scope”, and a set of goals.
3. The requirements project for each application under development is initiated with these objectives and boundaries.

What if you are tasked with defining the ecosystem, instead of defining a product within a pre-defined ecosystem? How would you go about it?

• The architect makes design decisions about what each system in the architecture does.
• The developer makes design decisions about what each class in the application does.

Isn’t this just design, writ large? Why should business analysts or product managers be involved? This is just an implementation activity on steroids.

What We Are NOT Talking About

There is a very good article at IBM that defines architectural requirements as application requirements that have significant impact on the architecture of a single application. That is not what we are talking about. Here’s a link, since that is a good article – if that’s what you were hoping to read today.

The Lifecycle of Creating Software

In One Man’s Trash, we looked at the life cycle of developing a software product from the perspective of the contributors to that product.

Our analysis was of a single product – not an application that has to live in an ecosystem with other products. That analysis showed four layers of solving the problem, but only one meta-layer of solving the problem.

In the uselessly big picture view, there are multiple layers of “requirements” and “design” throughout the life cycle. When defining requirements within the “single software product” scope we wrote about before, most of the following is actually a distraction.

1. Companies and individuals have money to invest, and they have goals associated with those investments.
2. They will choose a mix of investments, where that mix is designed to achieve a set of objectives.
   1. Manage volatility
   2. Generate ROI (where the return is utility, but is easiest to simplify as a financial return)
   3. Mitigate risk
3. Within the constraints imposed by that mix strategy, they design a portfolio. That portfolio delegates roles to individual investments. Investment 1 is responsible for generating a high return at a high risk. Investment 2 is responsible is designed to hedge investment 1, mitigating risk while reducing overall return. Investment 3 may be responsible for generating a smaller, but highly reliable return. Each investment thus has a scope and a set of goals.
4. If one of those investments is in a company, it now has a scope and a set of goals – and a large company will develop its own portfolio of investments – choices in how it allocates funds internally. One of those investments may be a choice to operate in a particular industry, where those operations are defined by a set of goals and constraints. [Note – conglomerates may have additional, recursive sets of layers 1 through 4, as they manage a portfolio of companies.]
5. Those operations may manifest as a set of business processes, initiated by people using software, and supported by other systems internally. The choice to use people, or software, and how to organize the systems is one of design.
6. Once that design choice is made, each individual piece of software has a defined scope – a set of responsibilities within the larger architecture. And those responsibilities become goals and constraints within the context of a set of contracts between the systems. The entire chart above lives within this one step in the bigger picture.

When managing software requirements in the typical enterprise software project, this scope and these goals is already defined. Here are a couple examples of an application being defined within an enterprise architecture:

• A company needs to employ direct sales reps to sell their products. The company has a software application that the reps use to sell the products, and that application is integrated with another system that manufacturing uses to fulfill the orders. An accounting system also exists that is responsible for collecting funds due for each of the orders. Sales reps have to be compensated for their work, and a compensation system is identified to calculate sales rep compensation. It must be integrated with the existing systems and is responsible for determining how much the reps should be paid. The compensation system must integrate with the payroll system that is responsible for paying the sales reps.

Each of the applications (sales, fulfillment, payroll, collections, compensation calculation) has a defined role to play in the architecture. A typical requirements project would be to define the requirements for the compensation system. It helps to understand the ecosystem – the context in which this product has defined responsibilities – but that is generally a constant, not a variable. So, most requirements books, tools, and techniques are designed to operate with a presumption of a fixed set of goals and scope. The goals and scope of the product usually need to be discovered and validated, but they are perceived as immutable – at least within the timeframe of the project.

“Standalone software product” product management operates under essentially the same principles – the company is assumed to have a strategy, a target market, goals and a scope for the product. Requirements work for a standalone product is similar to the requirements work for an enterprise application that “knows its place” within an enterprise architecture.

But what about the requirements that drove the enterprise architect to choose an approach that involves separate applications for sales, fulfillment, collections, payroll, and compensation? These are architecture requirements

Defining Architecture Requirements

We know how to define and manage requirements within a predefined environment. Start with goals, and work our way down to “design.” Other people on the team will start at design, and continue through development, test, deployment, and adoption. This is a pretty comfortable environment. It is also an effective environment. When a problem involves the interaction of multiple systems, an efficient way to tackle that problem is through decomposition. Just as an investor decomposes a portfolio into individual investments, a company will decompose enterprise software into multiple discrete systems. And a developer will decompose a single system into multiple classes (or multiple modules, each made of

And we know the importance of requirements – the most successful teams don’t go immediately from goals and constraints to development. Multiple studies demonstrate the cost-effectiveness of using requirements effectively to prevent mistakes in implementation. It stands to reason that we are missing an extremely large opportunity if we don’t apply equivalent rigor to the architectural decisions that lead to the definition of those goals and constraints. So how do we go about defining the requirements that feed into the architecture?

Here’s a really good article by Scott Ambler that provides a more detailed perspective, and practical guidance for enterprise architects. The rest of this article is geared towards business analysts who find themselves supporting enterprise architects pursuing a path like the one Scott describes.

The first step is to identify the business processes – all of the business processes that are relevant. Using our example, these are the compensation-management processes, sales and fulfillment processes, payroll processes, and collection processes.

Part of defining these processes is identifying the stakeholders. We’re dealing with a much larger scope here – so valuation of the different stakeholder goals becomes much harder. It is easier to prioritize “sell bundled products” versus “sell customizable products” than it is to prioritize “pay sales reps” versus “fulfill orders.”

A very high level view of the processes is enough to do an first iteration of an architectural design. This is also sometimes called a straw man architecture, or candidate architecture. Notice that we said “first iteration.”

The next step – and arguably, it is a concurrent step – is to define the boundaries between those systems. Where / when does the order placement system (first system) transfer responsibility to the fulfillment system (second system)? And what does the first system have to provide to the second system for fulfillment (and possibly collections and compensation) systems to do their jobs? And how must those systems respond? What information must they provide to meet user requirements? What information must they provide to satisfy audit requirements or regulatory rules?

While this looks like design, I would argue that this is also feasibility analysis. The architects are designing the enterprise architecture – or the system under development. But that system is also an input into the requirements processes for each of the individual applications in the architecture. The scope of each individual application is defined by the system boundaries. The goals for each individual application are a direct result of the responsibilities that are identified by mapping the business processes to the individual applications.

Now we have a candidate architecture, a set of identified business processes, and a mapping of those processes onto that architecture – defining the responsibilities of each system. This yields a feasibility analysis by the architects. They will take this assessment (and any identified gaps), and modify the architecture – adding or removing systems, changing responsibilities, and otherwise iterating on the candidate architecture. Then they will review and iterate again – until there is a feasible design – just as developers will invest in the design of an application until there is a feasible solution to meet the application requirements. And this process should involve collaboration with stakeholders, and revisiting (or even redesign) of business processes with the candidate architectures in mind.

Conclusion

Developing architecture requirements (and architectures) is an iterative layering exercise. As much as it isn’t “our job”, our contributions to defining the architecture requirements will not only serve to verify the feasibility of the architectural approach, but they will provide clarity about the role of each application in the architecture. And that clarity of purpose sets the stage for a more effective “traditional” requirements process for that application.

This will also cause a significant reduction in requirements churn later – as flaws at the inter-system level will be identified and resolved before application requirements get underway in earnest.