Traceability from Biz Strategy to Application to Data to Hardware…

Recently, I’ve had a number of conversations with folks regarding concepts at the enterprise-level mostly focused on traceability from some architecture concept to Business Strategy. After all, if someone asserts an architecture concept and it isn’t traceable to a Business Strategy there is a natural reflex to question its purpose.

Here’s a view of a simple model illustrating the relationship between major enterprise concepts.


Let me describe each model element to make the model more clear:

·         Business Strategy. This is the actual stated buisness direction that a company declares with the purpose of providing directional statements with measurable goals to its organization.

o   Purpose: Statement of business direction

o   Example: ‘Increase revenue in enterprise customer accounts by delivering large, industry vertical solutions by 10% in FY08’

·         Business Process. The collection of interrelated tasks that solve a particular issue.

o   Purpose: Manage how the business executes.

o   Example: Process Invoice, Assign Resource, Create Offering, Sell Offering

·         Application. An application is a software asset.

o   Purpose: Physical software which contributes directly or indirectly to automating a business process.

o   Example: Sharepoint, Excel, COTS Pacakge xyz, Custom-Roll-your-own system abc.

·         Data. Disorganized unstructured, structured or semi-structured information.

o   Purpose: What is stored by business processes and used to make business decisions.

o   Example: Customer address street name, Packaged offering SKU abcdef item description, image file

·         Hardware. Infrastructure of interconnected devices which host IT systems.

o   simplePurpose. Physical computer hardware which host IT systems.

o   Example: Server, switch, desktop, cables.

Being intimately familiar with these concepts is important for simplification, control or any other worthy endeaver to deliver value to your company.

Unfortunately, for large organizations these concepts are too detailed to manage and there is a need to abstract them while maintaining exclusivity between them - especially management of the business applications.

For purposes of brevity, I’m not going to talk about Asset Lifecycle Management or Application Portfolio Management specifically. The concepts I’ll introduce next are certainly related and complimentary to ALM and APM but do not cover them in their entirety.

For large organizations managing business systems I have to introduce a few more concepts to the picture; Business Capability, Solution Domain and Data Facet. The picture below illustrates these three concepts as addition model elements into the same view as above to help describe them in context.

·         Business Capability. A business capability is a business function encapsulating people, process, technology and data.

o   Purpose: Manage the major business functions of an organization to deliver on the Business Strategy

o   Example: Resource Planning, Offering Design, Sales Force Administration

·         Solution Domain. A Solution Domain is the highest level abstraction of a software system that represents a logical grouping of system functionality which master Data Facets.

o   Purpose: Analysis tool to rationalize business software systems and provide guidance for building core business system services for an enterprise.

o   Example: Agreement Management, Selling Framework Management, Project Resource Management.

·         Data Facet. A Data Facet is a specific aspect, or particular view (among many views) of a subject area; a group of data that describes this aspect.

o   Purpose: An abstraction above a Conceptual Information Model or Business Objects and is used to define information across an enterprise.

o   Example: Software Product, Customer, Agreement

In the Microsoft IT Enterprise Architecture program, we’ve built out taxonomies for each of these concepts with the purpose of improving our ability to manage our IT assets and ensure their integrity and quality as well as mapping them to Business Strategy.

With them, we have discovered some interesting principles that balance the relationships between the business and IT in very simple models. They are quickly becoming fundamental for our work.

I’d love to hear other ideas for achieving the same goals. Do you use something similar or different?

Comments (14)

  1. Gabriel Morgan knocks one out of the ballpark in this blog post that traces the connection from Business

  2. So, where does the concept of an IT Service come in? This is something I have wrestled with mightily.

  3. Hi Charles,

    I’ve heard ‘IT Service’ used in several ways; a software service (eg .asmx or Operations of an .asmx), an organizational function within IT such as Operations Support or Application Portfolio Managment, or as a high-level abstraction of a technical capability such as Messaging. So, unfortunately I can’t directly answer your question with a known industry-accepted response because the term is illdefined.

    I probably lean to IT Service being synonomous with a Software Service becuase I mostly roam in Software Architect circles but I don’t get wound around the axels if it used differently.

    As you can imagine there are many different kinds of Software Services. A good taxonomy of generic Software Services descriptions has been defined in Shy Cohen’s article ‘Ontology and Taxonomy of Services in a Service-Oriented Architecture’ found here

  4. alphasong says:

    Please read this exchange and (if you are so inclined) I would love to know your thoughts.

    You might also be interested in my IT data architecture work – early version here:


  5. Hi Gabriel,

    do you have some information about how this models fit into the main enterprise architecture frameworks like zachman or togaf ?

    I mean, can this model be represented in terms of these EA framework views ?

  6. Hi Carlos,

    It is probably possible to map the concepts I used in the views above to cells in the Zachman framework or BA, IA and TA architecture views from TOGAF. I didn’t do this because the amount of added concepts in those frameworks loses the simplicity I think is necessary to gain understanding why an IT asset exists.

    The views above are really just another metamodel but different in that they simplify the relationship between Business Strategy/Goal/Objective/Need and an IT asset to help describe why an IT asset exists in a fashion that is very, very simple and applicable to a small organization or large organization.

    I arrived at this metamodel as a result of the approach defined in the IEEE 1471 spec for describing architecture models. The IEEE 1471 spec is a great way of building architecture models based on the concepts of Views and Viewpoints that filters the noise to focus on the point and, therefore, maximize the chances of communicating an architectural message.

    In my metamodels above, I wanted to address the Concerns "What are the major architecture concepts in an enterprise and how do they support the business?". I focused on the Enterprise Architects and Portfolio Managers Stakeholders becuase managing these concepts are what keep them busy. I chose an enterprise-wide Viewpoint to ensure coverage.

    It isn’t perfect and I don’t claim that it replaces an Enterprise Architecture Framework by any means. It is simply a filtered view from the same concepts in popular EAFs in my opinion. I consider it a simplified View of major EA concepts with the purpose of tracing IT assets to the business. I use it for for many things such as mapping exercises as part of application portfolio management, discussions on how SOA is relavent to the enterprise as well as a means of drilling down in the depths of software service design.

  7. I wrote a blog ( found here ) describing the relationship from Business Strategy to other Business Architecture

  8. Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture

  9. I recommend taking a look at Archimate which clearly shows where Application Services fit in the EA meta Model.

  10. @ Adrian

    I’m a fan of Archimate and, in fact, in my metamodel above, you might notice some thinking which is compatible from many of Archimate’s concepts (largely taken from the book "Enterprise Architecture at Work: Modelling, Communication and Analysis") however the Archimate language doesn’t define the concept of Solution Domains, Business Capabilities and Data Facets well enough and a bit of tweaking is necessary to make this work…but definitly workable in my opinion.

    My metamodel above is meant to be a simplistic view of the key concepts for an enterprise architecture and avoid overburdening it with the familiar overhead EAF’s unfortunately have out there today. Of course, what I’ve posted in this blog isn’t the whole story – it’s more of a just a taste of what I actually use to get the juices flowing and convey an idea. I wish I had the time to share more.

    Anyway, thanks for posting the Archimate link. It’s great to see others out there familiar with it.

  11. Modeling helps improve the success of delivering a high-quality solution A primary responsibility of

  12. Mark says:

    If it is not teaceable, it is not reproduceable, and it is thus not valuable.

Skip to main content