The Process Architecture of an Organization is an expression of the hierarchy of process and the sequences within and between those processes. There is a natural progression from process and function identification to procedure definition that may be followed. The Process Architecture should be held at the set / subset level of abstraction. Process Architecture may/should be mapped to business domains.

The Process Architecture of an Organization is an expression of the hierarchy of process and the sequences within and between those processes. There is a natural progression from process and function identification to procedure definition that may be followed. The Process Architecture should be held at the set / subset level of abstraction.

Process Ordering

• Sequence
• Repetition
• Alternation
• Recursion
• Concurrency

A Process Architecture is a hierarchy of processes, functions, and procedures.

What is a Business Architecture?

For most architects, this question seems one of the most hardest to understand.

The focus area of enterprise architecture focused on defining the future state
business model, organization and capabilities/services needed to satisfy ongoing
business transformation efforts.

An Enterprise Business Architecture (EBA) describes the various functions of an
organization, the business processes that support those functions, and the relationship
among the business processes. The EBA includes the current Business Objectives and longer
term Business Strategies of the organization as well as the Business Capabilities the
organization will require to achieve its long-term Strategies; and maps the supporting
business processes and functions.
BABOK Definition (V1.6)

The Business Architecture is a set of documentation that defines an organization’s
current and future capabilities. The Business Architecture describes the businesses
strategy, its long term goals and objectives, the high level business environment
through a process or functional view, the technological environment, and the external
environment.

An INDUSTRY PERSPECTIVE

The term Business Architecture is used for a broad range of very different artifacts and
activities. Vendors have introduced complex methodologies, sophisticated business modeling
tools as well as “meta-languages” for describing a business. We use the phrase ‘Enterprise
Business Architecture’ to denote that we are referring to BA in the context of EA-related
activities

In a number of organizations that are focusing on developing an EBA the lead responsibility
is often in a line organization and the EA team, as well as IT, is often not included
despite that fact that technology is often the key enabler of most business transformation
efforts.

The Business Architecture is a description of the organization and as such is very much
like the blueprint of a building. Its components include descriptions of the
organization’s data (domain data), processes, organization, and places (locations).

Its process / deliverable components include:

Capabilities List/Model
Business Strategy – goals and objectives
Business Drivers
Organizational Architecture
Data Architecture
Process Architecture – Business Process Models
Deployment Architecture
Business Architecture Relationships

The following example is a scenario in which the EA was used in setting Budgeting Strategy Direction

The following describes a scenario in which the Enterprise Architecture may be leveraged for pure business benefit:

A snippet from one of our case studies at Firefli Consulting Inc.

Eventually, we decided to reorient our architecture efforts toward providing the context and facts to guide planning decisions. But first we have to do some work. For example, if an IT department already has a well-defined technical architecture, but was focused on technology and tool standards, IT may have little connection to business applications. To supplement it, we might develop several architectural deliverables.

* A model of the business that identified key processes, constituencies and business capabilities.
* An inventory and map of the current state of our business application portfolio. We then overlay that on our current technology infrastructure.
* A target state for the business application portfolio.

With these in hand, we can engage in the next year’s annual planning process. We can map the proposed projects to the business model to see how projects related to each other. That allows us to identify project overlaps in terms of common or related business functions, such as data marts with a high degree of common information.

When it comes time to prune the list of proposals, we could suggest consolidating projects so that one single effort could support more than one business need. The overall economics of the consolidated projects is improved-more business benefit for a given unit of investment-and so was their priority for funding. IT resources could be focused on a smaller number of projects, resulting in higher quality and more reliable delivery, as well as a reduction in subsequent application maintenance.

Similarly, we might uncover many situations in which business areas are proposing projects that overlap with applications already existing in other areas. Because our IT groups may work in silos to some extent, they would not have been aware of the redundancies. We can now identify those cases and recommend either building on the existing applications or slating them for replacement.

Our architecture approach can allow us to proactively assess the fit of proposed projects with the current technical architecture and provide early on a critical heads-up of the risk or cost that will be involved when the fit is not good. Software upgrade plans, meanwhile, can now be compared with the proposed projects to see where they could affect a project’s timing or the cost to perform the upgrade. The project’s estimated cost is then adjusted to reflect this.

Let’s get right into it – the business architecture defines the future state business design. The Enterprise Business Architecture answers the question, “who is going to do what… differently?” relative to the business strategy work that has been done before setting out to do architecture.

The enterprise business architecture is a business vision driven, disciplined process, which decomposes the enterprise’s business strategies, the assets and processes required to execute them, as well as their impact on business functions. The Business Architecture is implemented through the enterprise’s information, technology and application architectures and defines the business design for sustainable competitive advantage.

Now that we know what it is, let’s look at what we need to create it. Artifacts of the business architecture consist of a requirements vision, a conceptual architecture, as well as current and future state models of business activity that articulate the organizations’ value chain.

Business Process Modeling is performed to answer the question “How do we make changes to our process(es) to make this strategy happen?” Business folks don’t typically have modeling tools. They likely don’t know how to use them and that is where we, as architects come into play.

Senior Business resources are the only people who understand how all of the business works together, but this knowledge can be so abstracted, we don’t know the detail. IT needs to take leadership to collaborate with them and make these processing activities happen, but NEVER should take ownership of the content.

The first step of the Business Architecture is reviewing the strategies created to change the business and derive business change requirements. The Second is to create a conceptual architecture, consisting primarily of principles (see previous discussions on this subject) to provide management direction. The third is actually modeling the current or target state.

The architect should model just enough, and just in time, so may start with very high level, conceptual models.

Capturing the current-state model is sometimes necessary, but the future-state model should be attempted with minimal constraints and limits imposed. It gets everyone moving and motivated quickly. Users need to be reminded that it represents the target and some or all of it won’t necessarily be implemented by IT.

A high level Use Case Diagram is often the preferred model of choice. A Venn diagram or some type of simple model to start is acceptable to model the business domains. The intersection should house the common business functions, and then other business functions can be listed and grouped in the intersecting circles. Lines may be drawn between them to show relationships. Circles around functions that are not within groups may be drawn outside of the major groupings to show they exist and for relationships. See www.BPMI.org for the Business Process Management Initiative’s thoughts on the matter.

Scope should include partners, alliances, customers and external business relationships. These areas can be used to create a three dimensional looked of the state of an organization. It depicts strategic alliances, mergers and joint ventures in future state diagrams. These diagrams can be used to analyze value in adding processes to the business. They enable benchmarking and competitive analysis. IT can help to challenge assumptions – “What if you could do this…”.

Linking work may be attempted at this time to being creation of the information catalogue with each business process and it’s domains or major business entities. This creates the link, and kicks you off in the right direction when you tackle the Information Architecture.

This is incredibly simplistic, but if you are looking for a start – this is where it is. It is very simply to show target state in this manner, and a quick future state can also be drawn to highlight the new and changed areas. These diagrams can become more sophisticated over time, as more information is needed, or as the level of interest is required in order to present or validate the information with business folks.

The bottom line is that business architecture value to an organization will not come from the models alone. Initiatives must follow to develop selected transformations within the business in order to drive change. Models which are linked must follow to further elaborate the models.

This is a Rational Unified Process Business Architecture from the Enterprise Architecture context view. The value of this particular view is that it includes the actors/users, the roles, the process and the artifacts.
– A reprint from our Architect Abstract eZine

Note: This article was published in one of the early editions of our eZine. How to get started with Business Architecture continues to be one of the most frequently asked questions around Enterprise Architecture today