Page tree

Architectural Thinking Framework

Skip to end of metadata
Go to start of metadata


8 Comments

  1. The approach for modeling business capabilities described here is a top-down approach. From my experience, better results can be achieved if a top-down approach is combined with a bottom-up approach. To this end, a step "Collect and apply business functions to revise the model" could be added before "Model Draft". Business functions are the actions required for a specific business capability. In the banking example, business functions related to the capability "Account Management" are "Create account", "Block account", "Close account", etc. The business function "Rate credit-worthiness" might also belong to "Account Management", but it might also be better assigned to "Collateral Administration" or "Risk Management". This has to be discussed taking into account the definition and characteristics of business capabilities.

    Step "Collect and apply business functions to revise the model" would run as follows:

    Collect the business functions of the enterprise (or a part of it). Possible sources are:

    • Detailed process descriptions
    • The functionality of existing IT applications
    • Business objects (i.e. the operations on them)
    • Interviews with experts of the business units
    • The scope of running or planned projects

    Then assign the business functions to the business capabilities defined so far. Take into account the definition and characteristics of business capabilities, in particular that within a business capability the mode of operation is similar. If necessary, revise the business capability model.

    The business functions (or examples of them) might also be displayed in the business capability map to explain the meaning of the capabilities. Alternatively (or additionally), the business functions can be listed in the half a page of text describing the capability.

  2. Michael Beck- does it look like top-down? That was not my intention. >>From my experience, better results can be achieved if a top-down approach is combined with a bottom-up approach.<< YES, YES, YES.


  3. Regarding business functions. I'm quite unhappy using two different terms that are hard to distinguish. Usually ends up with philosophic discussions of EAs, and I've had so many of them that wasted my lifetime.

    What we want to do with capabilities is a high-level management view where executives can base decisions on.


  4. Michael Beck - according to BIZBOK some capabilities of my example in this Wiki are no capabilities (e.g. sales channels).

    For me - a Capmap is good if it is (i) understood by C-level executives in an Instant (ii) all boxes are important to connect strategic decisions to.


    What do you think?

  5. Comment on Slack: 

    I do a lot if teaching to EA/BA professionals.We sometimes have a hard time explaining the point with bus capabilities to people with a process background. We find that the definition of a process have changed since Hammers and IDF0 statement of showibg the process with the trigger, result, resouces used,  the guidance from rules, strategier etc. In most cases the process is only the things that is done. In EA we have split this into process, information and ITsystem and sometimes a business modell (refering to the strategic direction).When we introduce the business capability as a composite of everything you need to perform a specific task, sales, product pricing, Customer invoicing, etc most people find the combinations of all you need, process, information, it-system, people, business rules, etc intuitive.We make a big point of this not beeing a fifth perspective but rather something that combines the four trad EA parts (and then al lot more) into parts of the enterprise that work as a whole with know dependencies. Bus capabilities are connected to each other via business services, a bus cap offers a number of bus Serviced to others and in most cases a bus capability needs to use business Serviced from other bus cap to be able to perform this ”task”.As some of you might know we, IRM, use a design pattern for the cap map based on the business geography derived from the overall value flow of the enterprise.When we build/create/design the map we ask ”what is it that you do in each steg of the value flow, what IT-system do you work in and what information do you use, get from others and offers others”. With these questions we are able to create bus cap maps that are percived as intuitive and easy to understand and use in variuos situations.We have used material from Forrester and the cutter consortioum as a base for some of our thinking along with a lot of blogs, linkedin discussions and practical experience.

  6. Hi, That is my comment from Slack. /Annika

  7. My questions regarding this question....."what is it that you do in each stage of the value flow, what IT-system do you work in and what information do you use, get from others and offers others” 

    What roles are typically engaged in participating in ?   senior leaders - managers - HR/OD - front line (sales)  - support functions (finance)

    IT roles - developers, coders, DevOps, coaches, product owners????  

    What critical roles are not excited about being there or do not show up?  

    What scares them about implementing the work (making changes to their existing processes) 

    What might block cooperation?  

    ~ between departments, roles, functions? 

    ~ what are critical success factors (outcomes) if they apply what they take away? 



  8. Hi,
    Since I usally work with architects the starting point has been some where in the middle between the EA/BA and the PMO (or change prio/coordination/decisionmaking/execution). Since I started to do design sprints together with Milan I found a way to create a map really fast based on existing material like process maps.

    The roles involved in verifying the map is the once closest to the challenge we are trying to manage.

    I have the overall map in mind when I design the map but I learned the hard way the problem of creating a great map that covers everything is not a good way to get buyin from stakeholders.

    So I what to be close to a business problem/challenges and let the questions asked be the guide to what the map should make visible.

    Usally there is a business stakeholder, some architects (EA,BA, solution arch), one or more product owners (owner of something the org deliver to real customers) and some representation from the org i.e. marketing, sales, delivery, etc...

    When we run into problems it is usally when we start to use the map for prioritisation or as decision material. This is when the maps starts to be a ”political” tool, what org units are responsible for the bus cap? And How do we manage the balance between the value flows (owned by product owners) and the org units owning the bus cap supporting the value flows.

    I am currently in a new assignment in a very complex environment of three large companies initiating a cooperation. There is no way I can create a map for the entire scope now because it is way to complex. So instead I have made maps for each area of cooperation.

    I do think that if we are allowed to continue we will be able to create a map of the cooperation with connections to the internal business structures.

    A long answer but I hope my way of thinking is shown. //A

Write a comment…