Gabriel Morgan

Sharing experience as an Enterprise Architect, Business Strategist, Business Performance Manager, Business Architect and Solution Architect. Twitter:@Gabriel_Morgan

Enterprise Architecture Mapping Artifacts - They are very powerful so be very, very careful

Enterprise Architecture Mapping Artifacts - They are very powerful so be very, very careful

  • Comments 6

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.

Mappings

Value from the mapping

Risks

Assumptions

1

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.

 

2

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.

 

3

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.

 

4

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.

 

5

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'.

 

6

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.

 

7

Technology Capabilities to Applications

· Simplified product-agnostic technology portfolio.

· Confusion for what capabilities Applications or technologies provide or consume (primary or secondary).

 

 

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • PingBack from http://msdnrss.thecoderblogs.com/2007/08/16/enterprise-arch-mapping-artifacts-they-are-very-powerful-so-be-very-very-careful/

  • I realised it had been a long time between postings but just how long surprised me. Since I last blogged

  • What exactly is an Enterprise Architect versus a Solution Architect? I'd like to chat about the difference

  • An enterprise architect's scope is to look at all solutions as they apply to the enterprise. This could include identification of duplicate functionality between systems, business process modeling at the enterprise level, understanding of legal and localization requirements for each country/region, and much more. We tend to be very broad in our architecture knowledge in all areas of IT including telecommunications, networking, servers, application development, databases, facilities, security, and more. aka Jack of all trades, master of none.

    As a solution architect, we tend to be more focused on solving the problem in which the solution solves. We interact with enterprise architects and various other architects such as database architects, application development architects, network architects, etc.

    Hope this helped.

    Scott Peal

    Lead Enterprise Architect

    Burger King Corporation

  • Since I am not able to view the entire contents because the table is too wide.  How can I get a copy of this?

    Thanks,

  • @Amcosentino

    One option is to copy and paste the blog post into a Word document if changing your screen resolution cannot be increased.

    I shouldn't have to force others to anything to read these posts. So, from this point forward, I'll post articles at a lower resolution setting to avoid this problem.

    Thanks for bringing this to my attention.

Page 1 of 1 (6 items)