The Idea Card

Whatever business you are in innovation is the name of the game. Today it’s even more important than ever that you innovate fast and somewhat accurate. This little card is designed to help you go fast by staying small and keeping it nimble.

The_Idea_Card

When you should use this

  • Whenever you need to innovate
  • When you need to keep a trail of successful and failed ideas

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • Print many large copies and put the on walls
  • This card is best used as a communication tool in collaboration between teams

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Download
You can download the presentation here

Post change log
2015-10-29: Published initial post

Advertisements

The Entity Card

Whatever business you are in, information is the most important raw material there is and it should be understood by many. Using tools like the entity card is one way of communicating on relatively stable information structures, there are other ways. People may say this is hard and takes a lot of time todo. To them I would recommend that they think about the basic information used in the business and evaluate for how long the average entity has been around. My experience is that most entities within a business domain has been around at least +80% of the lifetime of that domain. Changes to the entity is almost always on business rule or attribute details.

The Entity Card

When you should use this

  • Whenever you set about designing an entity you can use these questions to understand the shape and use of the entity in scope
  • When you need to document in some detail a key entity

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • An entity in the overall information architecture is just one piece of the puzzle
  • This card is best used as a communication tool in collaboration between agile teams and architects

 

License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log

2015-10-15: Published initial post

Event based processing and capability architecture

The illusions of process architectures

Most of the time people expect that a process is a linear execution of activities that has been predetermined, some people call this the happy path (top illustration) and expect that this is the way things should work. On other occasions people realize that processing is a bit more complex and adds in what they see as the alternative routes a process can take (middle illustration). These two views of processing is how almost all process architectures are expressed. In reality though processing from a business perspective is a jumble of alternative paths (bottom illustration) and it’s all but impossible to know before hand what the process would look like.

The illusions of process architectures
The illusions of process architectures
Sisney (2012, l. 1406) writes that `adaptation to the environment is supreme and fitness or capability is always secondary´. This fits well with my view on the notion of dynamic processing and agile businesses.

Bloomberg (2013, p. 101) writes that `the end results are dynamic processes that have no predetermined flow. Instead, the people involved in the process begin with the goal for the process and then the technology supports the interactions among the people in order to achieve the goal´. This fits well with my assumption about processing as only dynamic activities that have no predetermined flow.

The traditional process view on a business solution architecture

This is the way most process views are expressed and it sucks. It sucks because it forces the business to become stale. It sucks because it forces the information systems into rigidity and complexity. After a couple of months or years people find new ways of working and there will be variations to the services offered. At that time it will become increasingly difficult to make changes in the systems and the business will suffer. The lead time from idea to realization will be longer and longer and complexity will increase until the system collapses under its own weight.

Traditional view on business solution architecture
However it is not all bad with the traditional way of doing process architectures. Considering the fact that the same activities could be activated in the same order repeatedly we would leave tracks in our logs. Those tracks we could refer to as processes. By stitching those processes together we could use them as generic processing patterns, which would enhance our understanding of the overall behavior. From a systems execution standpoint tracks would enable us to reach higher performance, since we would not have to start from scratch all the time.

Agile processing view on a business solution architecture

Richards (2015) writes that `Claims processing is a very complicated process. Each state has different rules and regulations for what is and isn’t allowed in an insurance claim. For example, some states allow free windshield replacement if your windshield is damaged by a rock, whereas other states do not. This creates an almost infinite set of conditions for a standard claims process´. The complications on process variations that Mark bring to light in his book is one reason why going to a capability based microservice architecture is the right thing to do for many information systems.

The processing dimension depicted in the illustration below is to be considered as a generic processing pattern. If you where to interview a business expert this is how you like them to describe their work. Knowing this we could start asking the business expert for each activity what it really is they would like to achieve by performing that particular activity. The result from such an inquiry would be activity goals, these goals we could express in the architecture as activity events. If we did this transformation from activity goals to events we lay the foundation for freedom in processing and retain the ability to continue our conversation with the business experts.

Agile processing view on a business solution architecture
Agile processing view on a business solution architecture
The illustration above is a good representation of how I would recommend expressing parts of a business solution architecture. This way ensures that the architecture is future-proofed for the business and at the same time able to realize the promise of agility and scalability through digitization.

The event hierarchy is the foundation for dynamic processing

Events map naturally to capabilities and activities which gives us the guidance needed to allow the users infinite ways of executing a generic processing pattern. If we then choose to implement this business solution architecture as an event based software architecture we can support the users no matter how they choose to work as long as they satisfy the goals in the activity events.

The event hierarchy is the foundation for dynamic processing
The event hierarchy is the foundation for dynamic processing
The Elements of an event based goal model

  • The Market Events serve as a reflection of the goal a customer seek from interacting with the business.
  • The Business Events serve as a reflection of the goal a business seek from interacting with the customer.
  • The Activity Events serve as a reflection of the goal a role seek from interacting within the servicing of a business event.
  • The Transaction Events serve as a reflection of the goal an actor seek from interacting within the servicing of an activity event.

When you should use this

  • When business requires future-proofing the support they get from information systems
  • When you consider moving to an agile enterprise architecture
  • When you are set to create a microservice architecture

What you should consider when you view this

  • This is not “the complete, nor may it be the correct” views of any specific insurance company architecture
  • Continuously refine your events as you go down the capability hierarchy
  • When naming events think of each event as the goal to be achieved
  • In the end it’s all about just doing it

Related

Reference list

Download note:

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

Post change log
2015-07-10: Published initial post

 

Using the Capability Inventory for municipalities

Using the Capability Inventory for municipalities

I was talking to Marino the other day and he told me he would like a special capability inventory for a municipality. I said that there is no need to have a special capability inventory, the basic pattern exposed in the original capability inventory should cover any organization. In fact he should just use the original one and perhaps add the elements that are missing. The basic pattern behind the capability inventory is to view every organizations output as delivering services. This view enables us to use the same basic elements across all organizations. I can relate to the fact that the pattern and elements looks unfamiliar because it does not follow the way one is used to visualize a municipality. To remedy any confusions I´ve designed a naïve example below.

Elaborating on the capability inventory for municipalities
Elaborating on the capability inventory for municipalities

In the example I´ve removed the elements in the envision and enable rows and focused on the engage row. The text in the capability elements are not capabilities rather they describe the activities one would perform using the capability to reach the business goals.

When you should use this

  • Whenever you set about using a capability model of your enterprise
  • Whenever you have a new business problem to consider

What you should consider when you use this

  • Using the capability inventory and mapping out the basic activities will give you a good hunch but it is not the complete constructs needed to design the business.
  • It took me about 15 minutes to whip up the example

Download note

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log

2015-07-02: Published initial post

Capability architecture and microservices

The Elements of a Capability Model

The capability model could contain a lot of different elements but the basic ones are:

  • The Capability Areas which serve as a reflection of the functionality needed to run the business.
  • The Capability Groups which serve as blueprints for responsibility.
  • The Business Capabilities which serve as blueprints for business services.
  • The Resource Capabilities which serve as blueprints for microservices.

Frequently I use the capability model to project other elements on it. A very useful projection is visualizing the information ownership (entity groups, entities and sometimes even attributes) and the information responsibilities (business objects).

The Capability Information Model

The model below is an example showing ownership of information from a capability perspective. The model is the same as the one further down but it is focused on showing what information a capability group is the owner of.

Zooming into one of the capability groups (claim settlement management) we see that it contains information elements.

The Capability Collaboration Model

The model does not show every business object needed or created by the business capabilities, this is by choice. The  aim here is to show what a capability collaboration model looks like. The main objective on a capability collaboration model is to show the information responsibilities.

Part of an insurance company capability architecture

Whenever you start to develop a capability architecture you will soon need to verify that the boundaries are where they should be.

How to build the model

  1. Start by taking one of the business capabilities and look at what information it need that it doesn’t have in it´s own context. The business capability will need this information to do it´s work and to generate the outputs it is responsible for, as a result you get business object candidates.
  2. Assign the business object you´ve identified to the one business capability that would generate it.
  3. Draw an arrow from the providing business capability through the business object ending up on the consuming business capability.
  4. Continue with tying the string between every other business capability that you found. Follow the steps 1, 2, 3 and 4 until you´ve exhausted all identified capabilities.

Rules of thumb

If you find business objects appearing out of nowhere then it is a fair assumption that either the consuming business capability is wrongly specified or there is a providing business capability that has not been identified yet.

If there is reason for it then you should include business capabilities that belongs outside of your corporate context.

A definition of a business object

A business object is defined as a specific set of entities representing the total amount of information needed by one business capability from one other business capability.

Business object is part of the information domain in the Inventory Model (EA framework).

When you should use this

  • Whenever you set about designing a capability model of your enterprise
  • When you are set to create a target context map for microservice architectures

What you should consider when you view this

  • This is not “the complete, nor may it be the correct” capabilities of any specific insurance company
  • Continuously refine your capabilities as you go
  • When naming capabilities think of each capability as part of a namespace
  • In the end it’s all about just doing it

Other things to consider from a capability model

The organizational perspective

  • If you work in an agile inspired environment then the capability groups gives guidance to where product managers would be responsible.
  • Teams should be set out to take responsibility for governing the business services realizing business capabilities.

The service perspective

  • The only way to access information governed by a capability group is through the business capabilities inside.
  • Each capability group is the sole provider of it´s business objects.

The realization perspective

Realizing a capability architecture can be done in many ways

  • The monolith pattern would use the capability areas as system boundaries and capability groups would then be represented by subsystems.
  • The service pattern would use the capability areas as knowledge boundaries and capability groups as information boundaries. Business capabilities would be used to orchestrate access to sets of microservices (resource capabilities).

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Download note:

I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

Post change log
2015-06-30: Published initial post
2015-07-01: Minor spelling adjustments

The Capability Inventory

This model is part of my toolbox for working with capability architectures.

The Capability Inventory

I know that there is certain ways of naming a capability and also that there are other principles that people and I promote that you should adhere to when designing your capability map. Here I’ve taken some liberties in regards to those principles to make it easier to relate to the possible content in the boxes. This inventory is basically what I refer to as “functions as capabilities“, now there is certainly a way of mapping proper capabilities into this inventory.

The Capability Inventory Details 

Detailing production
Details of production capability

Philip asked about the production capabilities so I’ve detailed some parts of production (above) to show where they could be situated. The detailed inventory map also shows how one can reuse the original layout to keep things in view.

Details of the sales capability
Details of the sales capability

 

Details of the marketing capability
Details of the marketing capability

 

I have some more of these laying around in different formats and states of publicity. When I find the time I’ll update this post with more of these.

Download note: I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

  • Whenever you set about designing a capability model of your enterprise
  • When you need to understand what types of capabilities an enterprise can have
  • When you are set to create a target context map for microservice architectures

What you should consider when you use this

  • This is not “the complete, nor the correct” inventory of capabilities
  • There is no known right way of designing or describing a capability of an enterprise
  • There is techniques like reversing the names of processes and then consolidating them that could give you a fair hint of what capabilities you have in your enterprise
  • Look at other peoples capability inventories and take inspiration from those
  • The “best” capability inventory is the one you get enough people to use in their work
  • Develop the capabilities and the capability inventory in as wide spread community as possible
  • Continuously refine your capability inventory as you go
  • When naming capabilities think of each capability as part of a namespace
  • In the end it’s all about just doing it

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log
2015-06-15: Published initial post
2015-06-20: Added the detailing view of production
2015-06-22: Added the detailing view of sales
2015-06-23: Added the detailing view of human management
2015-06-23: Updated the basic inventory of capabilities to reflect the sales capabilities directly
2015-06-24: Added the detailing view of marketing

The Inventory Model

This model is part of my toolbox for working with business architectures.

The Inventory Model

THE ENTERPRISE INVENTORY

 

The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in the X, Y or Z axis as you see fit for purpose and make sure to deliver something of value.

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

  • Whenever you set about depicting the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-19: Published initial post

The Strategy Model

This model is part of my toolbox for working with strategic architectures.

The Strategy Model

The Strategy Model

 

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

  • Whenever you set about understanding the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-12: Published initial post

The Scenario Canvas

This little canvas is part of my toolbox for detailing and documenting scenarios.

The Scenario Canvas

The Scenario Canvas

 

Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.

When you should use this

  • When designing target architectures I tend to use scenarios in conjunction with capabilities to help navigate the uncertainties of the future. (How this is done will be covered in a later post)
  • In the HBR article Living in the futures, Angela Wilkinson and Roger Kupers highlight how Shell has used scenarios.
  • In the McKinsey article The use and abuse of scenarios, Charles Roxburgh highlights some great insights into when and how to work with scenarios.
  • In the Forbes article Scenario planning and strategic forecasting, Jan Ogilwy presents a way of doing scenarios and also an interesting graph on what tools people use to peak into the future.

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-04-26: Published initial post