I wrote a blog (found here) describing the relationship from Business Strategy to other Business Architecture concepts and several IT concepts. I also introduced a few new concepts to the traditional view; Business Capabilities, Solution Domains and Data Facets that are fundamental to manage larger enterprise organizations. I’d like to reference that blog and the definitions of the concepts to talk now about how these concepts are used in portfolio mapping artifacts and share with you things that I’ve learned.
The following mappings list is by no means complete. My intention is to start a list and fill it in as I learn more. My intention is to bring awareness of mappings that I’ve observied having proved useful, mappings that have been less successful and throw in some related risks and assumptions as a way of added education to keep in mind when considering a particular mapping artifact.
One overlaying learning to all of these mappings I’d like to stress “Know what you are doing and clearly understand the goal“. Compromises will innevitably happen so remember to avoid being distracted with the realities of the data you must work with. It is easy to lose sight of the goal and end up making compromises because one of the mapping concepts isn’t entirely there or is poorly defined or is inconsistent, etc – you might end up with an artifact labeled correctly but containing data that is totally useless to addressing the goal. Know the risks and assumptions associated with a mapping so that you can make wise decisions what to do with it and how to communicate it so that it isn’t misinterpreted downstream.
As always, feedback is very welcome.
Value from the mapping
Business Strategy to Business Capability
· Know what major buisness functions are needed to deliver on the Business Strategy.
· Manage major KPIs tied to Business Capabilities that will delivery on the Business Strategy.
· Lose sight of important business functions that perform average or relatively well b/c usually Business Capability maps tend to draw the reader’s focus on the poorly performing Business Capabilities.
· Business Capabilities represent all Business Objectives. There are times when Business Objectives are spread between several Business Capabilities and Business Capability abstraction levels.
Business Capabilities to Business Processes
· Know what process traverse Business Capabilities, therefore ‘connecting’ Business Capabilities. This allows for planning of what Business Capabilities are improved when Business Processes improve.
· Know what ‘major’ Business Processes to investigate for improvement to improve a Business Capability.
Business Process to Solution Domains
· Simplified business systems view based on Business Process activities.
· Simplified standard business system interfaces for ‘macro’ Software Service and subsequently Application reuse.
· Application models are largely defined.
· Lose sight of business system stability because Business Processes change frequently and there is a looser tie to the more stable business views via Business Capability models.
· Business Processes are rationalized.
· Business Process Activities are relatively stable.
Solution Domains to Applications
· Simplified business system portfolio.
· Simplified data/information architecture, Application architecture/design guidance and policies.
· Lose sight of Technology Capabilities and therefore sub-system/non-functional Applications are not rationalized.
· Application functionality/features clearly map to Solution Domains.
Business Capabilities to Applications
· A view of what Business Capabilities use software and which ones don’t.
· A list of business application features which support one or more Business Capabilities.
· False indicator of application redundancy.
· Although Business Capabilities contribute to rationalizaing Business Processes there is a risk of it being a false indicator of Business Process redundancy.
· Difficult to quantify the portion of an Application for how it contributes to a Business Capability.
· Confuse Business Capabilities as reflecting Software Services.
· Confuse Business Capabilities as reflecting Business Processes.
· All Business Capabilities require software.
· Business Capabilities represent business needs or ‘features’.
Business Process to Applications
· A view of what Business Processes have supporting Applications and which do not
· False indicator of redundant Software Services based on Business Process Activities.
· Lose sight of the importance of business information.
· All Busienss Process Activities reflect software services.
· Naming and granularity of Business Processes are rationalized across the enterprise.
Technology Capabilities to Applications
· Simplified product-agnostic technology portfolio.
· Confusion for what capabilities Applications or technologies provide or consume (primary or secondary).