Web Age Solutions: Premier Provider of Technology Education and Mentoring

Kyle Gabhart

Subscribe to Kyle Gabhart: eMailAlertsEmail Alerts
Get Kyle Gabhart: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Objective-C Developer, The Role of Business

Blog Feed Post

Business Architecture – Functional Model

Across my client base, one of the most misunderstood architecture domains is that of Business Architecture.  This is terribly unfortunate, because Business Architecture is the cornerstone for any successful Enterprise, Solution, or Project Architecture.  Ultimately, it all needs to be grounded in the business needs and target objectives.  Otherwise, what’s the point?

To crystalize the concept of business architecture, it helps to examine the models and artifacts that are used to elaborate a particular organization’s business architecture.  In this post, I will explore one of the core aspects of business architecture – the functional model.

Functional Models answer the WHAT (and also sometimes the WHY)

A functional model provides a strategic view of how the business architecture delivers capabilities that align with business goals and drivers. This model answers the question:

“WHAT functions does the business require and how does the architecture align to this functionality?”

A functional model provides a macro-level view of what the business does so that the technology organization can support that functionality through processes, data exchanges, integrated systems, and enabling infrastructure.  It gives a complete picture of what the enterprise does and plans to do.  Moreover, it provides a mechanism for articulating how the business will evolve – new business functions, modified functions, outsourced functions, obsolete functionality, and any other defined changes that are required in order to realize the desired future state of functional business delivery.

A secondary question answered by the model is:

“WHY do these functions exist?”

This is where the question of value or business driver comes into play.  Each identified function must tie back to something the business cares about in order to be a valid part of the functional model.

Two Sub-Models

Typically a functional model includes a construct that identifies business functions or capabilities and maps those to business motivators such as drivers, goals, or objectives.  At its core, a functional model is aiming to answer two questions.  The primary question – WHAT does the business provide or deliver to customers and then a secondary question – WHY does that matter to the business (i.e. what’s the value?).  The bulk of a functional model deals with the WHAT (the functions), but these should always be mapped against the WHY (the business motivators) as illustrated in Figure 1.

Two Functional Models

 Business Motivation Model

The first model captures business motivations and links them to business units and/or business functions (part of the second model).  The aim of this model is to capture what the business wants to achieve and link it with the enabling mechanism within the enterprise that delivers on that vision.  At one level, this helps to ensure that all of the elements of the business’s target outcomes are accounted for within the business architecture.  Conversely, it also ensures that every business function and enabling support within the enterprise model is explicitly tied to a goal or objective that the business wants to achieve.

There are multiple approaches in the industry for modeling business motivations:

  • TOGAF’s Goal / Objective / Service Model – TOGAF defines a Motivation extension to its Content Metamodel that defines Drivers (internal / external motivating condition), Goals (high-level statement of intent or direction), and Objectives (time-bounded milestone to demonstrate progress toward a goal).  The Goal / Objective / Service model specifically creates a linkage between business targets (goals & objectives) and the business services that enable the fulfillment of these targets. Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html
  • OMG’s Business Motivation Model (BMM) – Identifies Ends (Vision, Goal, Objective) and links those to the Means (Mission, Strategy, Tactic, Directive) by which you achieve those Ends.  Finally, the Means are further linked to Internal Influencers (Strengths and Weaknesses) and External Influencers (Opportunities and Threats) and then ultimately mapped to other business model elements such as Organization Units, Business Processes, and Business Rules.
    Source: http://www.omg.org/spec/BMM/1.1/PDF/

Business Capability Model

The second element of a functional model is the elaboration of functionality in the form of a portfolio of business capabilities, business processes, business functions, or business services.  The decision on which construct to use depends largely upon the overall direction that the organization is going strategically.

  • Capability models support business functionality threads that run through multiple lines of business
  • Process models enable orchestration and workflow styles of integration
  • Service models drive toward reuse, composite solutions, and promote contract-driven interfaces
  • Function models promote a componentized view of the enterprise and support modularity

To a certain extent, every business has capabilities, processes, services, and functions.  By selecting one of these to represent the second-half of the functional model you are making a statement as an organization regarding what the emphasis will be within your architecture.  In any case, we are aiming to capture what the business does in order to deliver on the vision articulated in the motivation model.  These two models can be kept distinct and loosely coupled or you may choose to weave them together into an aggregate model that demonstrates the linkage between the business’s aims and the business’s capabilities to deliver on those targets.

Here again, a number of approaches exist for modeling business functions, services, processes, and / or capabilities exist.

  • TOGAF’s Business Footprint Diagram - Describes the links between business goals, organizational units, business functions, and services, and maps these functions to the technical components delivering the required capability. A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified. Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html
  • TOGAF’s Business Service / Function Catalog – Identifies organizational capabilities and demonstrates the relationship between business services and technology functions.  Furthermore, it can be mapped against organizational units to demonstrate ownership of business services. Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html
  • TOGAF’s Functional Decomposition Diagram – Provides a graphical depiction of the information captured in the Business Service / Function Catalog (see above).  Also provides a very natural mechanism for eliciting the technical capabilities necessary to fulfill business needs.  One unique facet of this diagram is that it can easily illustrate shared components (which are more challenging to represent with a catalog artifact). Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html
  • OMG’s Business Capabilities View – Describes business activities, aligned against the organization that delivers that function (much like the other capability mechanisms).  One unique element of this view is the categorization and depiction of functions as customer-facing, supplier-facing, management-focused, and execution-centric. Source: http://www.omgwiki.org/bawg/doku.php
  • MODAF’s Strategic Views – Define a whole range of capability artifacts.  Typically MODAF is a better fit for highly technical engineering environments with heavy system integration requirements.  Additionally, a non-defense meta model would have to be crafted to retrofit this for Chubb.  The extensive set of integrated capability artifacts is still worth exploring either for direct usage or to inspire a custom solution for the enterprise. Source: http://www.modaf.org.uk/

One purpose of the capability model is to identify the spectrum of business functionality now, in the near-term, and in the long-term future.  It can be used to assist with strategic architecture planning to highlight what capabilities will persist, those that will be modified, capabilities that will be added, and those that will be removed as the organization progresses to the desired, future state.  A formal capability-based planning approach could even be adopted, leading to a need to map an organization’s initiatives, programs, and project portfolios against the set of capabilities that these efforts will impact. Source: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html

 Business Architecture (It’s like a real career or something!)

Business Architecture has come a long way in the last several years and its maturity and its scope extend well beyond merely analyzing business requirements and creating some process models (these are actually the domain of a business analyst or a business modeler). Now it is a full-blown architecture discipline with real models and meta-models supporting it.

In trying to help organizations come to grips with the realities of business architecture, I will often tell them the following:

While not every organization formally recognizes it, your business has an architecture.  It’s either the intentional one that has been created by the steady hand of one or more architecture practioners, or it is the ad-hoc one that you have stumbled into based upon tactical decisions that have been made over the last 10-15 years.

So it’s not a question of whether or not your organization should decide to do Business Architecture or not.  It’s a question of whether you want to be strategic and intentional about how you structure the architecture for your business.

Read the original blog entry...

More Stories By Kyle Gabhart

Kyle Gabhart is a subject matter expert specializing in strategic planning and tactical delivery of enterprise technology solutions, blending EA, BPM, SOA, Cloud Computing, and other emerging technologies. Kyle currently serves as a director for Web Age Solutions, a premier provider of technology education and mentoring. Since 2001 he has contributed extensively to the IT community as an author, speaker, consultant, and open source contributor.