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
Anonymous
August 01, 2007
Gabriel Morgan knocks one out of the ballpark in this blog post that traces the connection from BusinessAnonymous
August 09, 2007
So, where does the concept of an IT Service come in? This is something I have wrestled with mightily.Anonymous
August 09, 2007
The comment has been removedAnonymous
August 10, 2007
Please read this exchange and (if you are so inclined) I would love to know your thoughts. http://blogs.pinkelephant.com/index.php?/troy/comments/naming_it_services/ You might also be interested in my IT data architecture work - early version here: http://erp4it.typepad.com/erp4it/2005/08/a_data_architec.html -CharlieAnonymous
August 12, 2007
I have posted some thoughts here: http://erp4it.typepad.com/erp4it/2007/08/the-evolving-do.html -ctbAnonymous
August 14, 2007
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 ?Anonymous
August 14, 2007
The comment has been removedAnonymous
August 16, 2007
I wrote a blog ( found here ) describing the relationship from Business Strategy to other Business ArchitectureAnonymous
August 29, 2007
@ Charlie, I took your recommendation and commented on your blog http://erp4it.typepad.com/erp4it/2007/08/the-evolving-do.html.Anonymous
August 29, 2007
Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise ArchitectureAnonymous
September 24, 2007
I recommend taking a look at Archimate which clearly shows where Application Services fit in the EA meta Model. http://www.telin.nl/NetworkedBusiness/Archimate/ART/index.htmlAnonymous
September 24, 2007
@ 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.Anonymous
June 28, 2008
The comment has been removedAnonymous
March 04, 2009
If it is not teaceable, it is not reproduceable, and it is thus not valuable.