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?