Requirements for Enterprise Architecture: First Look

the hague
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.

requirements life cycle from different perspectives
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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

8 thoughts on “Requirements for Enterprise Architecture: First Look

  1. Great extensive article, thanks Scott.
    2 remarks.
    1) more often than not I have seen a definition of enterprise architecture (EA)in use that says EA consists of other architectures, or architectural views. Namely application architecture, business architecture, information architecture, security architecture and technology architecture. It seem syou are referring to application architectures when you say enterprise architecture.

    2) I wonder what you think about the situation: someone works at a company and finally finds out there already is a quite extensive application ecosystem and now calls it enterprise/application architecture. he or she will not start by a couple of requirements to ‘build’ the architecture, because it’s already there. how will he/she approach the task of building, maintaining, documenting the architecture? and how would the fellow BA help with it?

    Thanks for your comments.

  2. Hey Rolf, thanks for commenting. I’m definitely referring to the logical application architecture. Sorry for not clarifying that.

    In situation 2, there was already a “requirements gathering phase” that lead to the existing architecture. In the time since then, the business has changed (and the architecture has probably changed too). The question to drive after is “What work needs to be done, to provide support for what the business needs to do now and in the future?” There will be cost-benefit analyses associated with the use, leverage, or enhancement of each application in the logical architecture. That’s how we’re approaching it now, and how I would suggest that others approach it.

  3. Love the blog, if i may ask, what software are you using? how much does it cost? where do you get it? If it’s not a secret email me some details wouldya?

    thanks in advance!

  4. Scott,

    Enterprise Architecture is such a loaded term with dynamic definitions while having has so much promise, and so much risk. In a large enterprise with a great deal of legacy applications, often duplications from various mergers, how applicable is the process of Requirements for EA? The efforts involved to produce valid requirements in such an environment are immense, and thus may not get funding. Additionally, change is the constant in IT so when the requirements are completed they will need updating. This assumes there was no “analysis paralysis” in the effort to begin with. Thus in the large enterprise an EA requirements approach may not be viable.

    I would also be interesting to hear your thoughts on documenting Business Process then mapping to the Applications as in the BEA white paper ( http://dev2dev.bea.com/pub/a/2006/03/enterprise-architecture.html ), and to some extent the Zachman EA framework (http://www.zifa.com ).

    Perhaps your comments were taken out of context from a holistic EA solution. I would like to here your comments on this approach. Thanks.

  5. Hey Bill, thanks for your comment and welcome to Tyner Blain!

    I agree that EA is a loaded term, and many people put different definitions behind it. In general, I view an architecture like this as a system of systems. The overall lives indefinitely (practically speaking), while the individual applications come and go. The business uses of the system also change over time.

    These two dynamics make it different from managing requirements for a single application. A large enough, modular application may exhibit the same characteristics (think of the evolution of Lotus Notes / Domino, for example).

    I’ve done the “map the process to the architecture” functional analysis work before, and I believe it is critical to the success of any large architectural initiative. It is also valuable to any small-scale initiative. For example, the duplicate code you mention as a legacy in your example may have been avoided by doing that analysis before the second (or third!) version was added into the ecosystem.

    I need to read the BEA white paper to address your later comments.

    I like the Zachman framework – and I like Zachman, too – I had the honor of meeting him last year at the IBRF conference. For an organization that is not using that approach, it can be an overwhelming framework to explicitly stand up. But you can easily use it to guide the “do these things” and “do this next” discussions. Keep a printout of the chart at your desk, and once you’ve started covering (or intentionally excluding) activities in each box on the chart, you can more easily introduce the concepts.

    I can’t speak anecdotally to the tradeoffs of using Zachman over the long haul, because I haven’t worked on an architecture (for a single client) for more than 18 months at a stretch. I’m usually brought in to either stand up a new solution, or to help implement significant changes to an existing one. I also haven’t worked on a mature architecture that had been managed over time within the Zachman framework before I became engaged.

    If anyone out there has comments about the challenges of managing a single ecosystem for more than a couple years, I’d love to hear them. The folks I’ve worked with have mostly treated things as a series of “critical business initiatives” that are addressed serially – with lesser investment in the long-term view.

    I’ll take a look at the BEA stuff – hopefully in the next week or two – and follow up.

  6. Hello Scott,

    I just stumbled over this blog entry — not sure you will see this comment since the article is a bit dated.

    I am doctoral student doing research on goals and architecture. I really like your diagram, and was wondering how it would extend to other roles in the enterprise. Such as enterprise architect, middle and upper managers and also customer and 3rd party organizations. I think i will try to extend the diagram in these directions.

    thanks,
    Dan

  7. Hey Dan, welcome to Tyner Blain. I’m sure the occasional comment slips by, but usually I am able to see and respond to all of them.

    Generally speaking, I believe the other roles in the organization will map either to the “Product Manager” or the “Lead Developer.” The rule of thumb I would use is to ask the question “Is the person acting as a stakeholder?”

    When the answer is yes, I would look at their “requirements” in the context of the current project – are those needs reflective of goals to be satisfied by the project, or constraints to be enforced? When they are goals, I think product manager. When they are constraints, I think lead developer.

    What do you think?

    Scott (@sehlhorst on Twitter)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.