The Digital Business

The current situation

There is a huge gap in insight as to what a digital business really is. Today when I hear business leders talk about going digital it’s mainly revolving around four scenarios.

• The first scenario is to connect all the systems together though some sort of integration.
• The second scenario is to reach the customer via apps over channels like smartphones, webb and make the experience omni.
• The third scenario is to automate as much of the work as possible via some sort of BPM effort.
• The fourth scenario is to put things in the cloud.

All four scenarios are valid efforts and should be taken into consideration as they will build a foundation for what needs to be. However this is not what defines a digital business.

Truly going digital means operating the business through a digital representation and this means that the models in the business repository has to (inter)face with reality.

The emerging situation

Principle #1: Don’t put anything in the repository to which you cannot attach a realtime data stream.

Why: All the things you have in the repository is a logical representation of something that is a real thing in a business perspective. Not collecting and displaying data from that real thing and associate that with the logical representation means that you really don’t have a clue about what is happening, what could happen and what will happen. To put it bluntly – you are just playing in the sandbox.

How: Attach the Customer, Financial, HR, Change and Production data streams to your repository, filter out the things that you need to display with the model element and put the rest on a query basis.

What: Use of complex event processing, analytics and decision support over the data in the repository means that early signs of change should be detected and action can be taken directly with a full insight into the consequence. Having this capability means that the business will become more efficient. On the inside you will have to redesign your workflows as they could now become automated by large and further the digitalization of the business.

Outcome: The business is agile, predictive and profitable in proportions never experienced before.

The Customer Card

It’s never been as important to reach outside of the business as it is in the digital world of today. From an architects perspective it is vital to be able to connect the dots between what is servicing and who is being served. This little card is designed to help you go fast by staying small and keeping it nimble. The design of the card does some heavy lifting by tying the outside to the inside through services and value requirements.

This Customer Card contains an example to make it easier for others to use the template card.

When you should use this

• Whenever you need to understand the service and how you are servicing the customer
• When you need to keep a trail from customer to service and deeper into the architecture

What you should consider when you use this

• Use this is a guide, change it to fit your needs
• Print many small copies and put in the hand of those who knows the customer
• Print many large copies and put them 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

Related

• The Brand Canvas (local link)
• The Capability Canvas (local link)

Post change log
2015-11-03: Published initial post

Foundations of book #2

I’ve been working on getting all the pieces together for my second book project. Now the book is starting to come together under the direction of some visual guides. If you have followed my posts throughout the years you will certainly recognize some of these guides.

The major thought
There are only two ways to increase profit known to man, one is to sell more and the other is to lower costs. Whatever action one may take it is geared towards a goal aiming to achieve one of the two increases in profit. Of course one can take parallell action trying to maximize both goals, but that generally has the efffect of not reaching satisfactory levels of any one goal. In a whole system approach as is the one I write about here, the optimum is a balance between the two forces. The result one would find generated by a perfectly balanced system would be greater than the sum of its own and the interacting systems parts taken together. To take it in terms of economy we are balancing Opex and Capex with Stratex (the budget that secures your future and funds innovations in business models ). Most managers find it in their hearts to go for portfolio management as a way of managing the the future. This focus on CAPEX would in general give them a controlling stake of somewhere between 5% and 20% of the overall budgets. Another interesting trait of portfolio management is that it is in effect run as a single year investment process much like OPEX.

Anywhere between 95% to 80% of the total budget is dead set in OPEX. This contains most of the actual power over the company. OPEX can be seen as a blocking force or a stabilizing force depending on culture and position.

The long term investments needed to ensure a rich future is most often unalocated for and are left to wither as long as major crisis is off the radar. In the end this may add up to more than the running operations of today just to fix the immediate problems.

What I intend to explore in this book is how to balance the three forces manifestated as OPEX, CAPEX and STRATEX by the use of an architected approach.

The foundation

The foundational illustration of the way

The foundation of the book are the thoughts that I expressed in the first book The art of Enterprise Architecture. I’ll merge the thoughts from the first book with the one-liner tweets collected in the post One year with #TheArtOfEnterpriseArchitecture.

The five E’s

The five E´s of the framework

The book follows the five E´s as a way of pulling together the thoughts and concepts into a set of coherent views. Each view contains subset views that could be used as a default guide towards what need to be known from a particular portfolio point of view.

Some elaborations of the Envision view

Ideation views

Environmental views

Team views

The Capabilities of the Enterprise

There seems to be as many ways of talking about capabilities as there are ways of putting a shoe together. To add to the confusion functions, processes and other concepts of enterprise architecture is widely used as capabilities. Here I refer to capabilities as the core skills that we must master as a social system (the organisational level).

Capability litmus test
To figure out if the concept we have before us could be a capability we need some way of testing the concept. The easy way of doing this is to run through the step process of

1. A capability gets better or worse every time you use it
2. A capability is something which by the way it is used can provide:
   • the same results in different ways in the same environment
   • different results in the same and different environments
3. A capability can briefly be described by:
   • A name
   • A description (with emphasis on the expected value)
   • An environment (in the context we expect to find the ability)

Capability principles
A capability can in some sort of detail be described by its constituent components
A capability is an organisational skill that requires the will of a superior system to be used.

Capability concepts
The purpose is to capture the capability concepts used in the enterprise.
Capability
Name
Description
Environment
Constituent components
Capability
People
Culture
Strategy
Tactics
Organization
Economy
Rules and Regulations
Processes
Information
Applications
Technology
…

Architecture in the domain of economics

Prioritization tool

 

Considering which features to realize should be dependent on time to market for the product and difficulty of realization. Properly used this little tool can help architects balance the organization cash flow.

Using this kind of diagraming technique it’s easy to get a comparison overview across many products.

 

 

The Project Business Model SWOT

This post is the sixth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model SWOT

This a simple SWOT covering the basic assumptions you have over the external and internal forces influencing the project. The enhancers are forces that work to make your project a success. The silencers are forces that work to make your project disappear from the change radar.

Make sure that you follow the business model component structure when outlining the SWOT, to ensure that people easily can relate the work back to the Project Business Model Canvas. When we design the SWOT cards we follow these three simple rules:

1. Internal forces should focus on business model components from the left side, that is Key partners, Key resources, Key activities.
2.  External forces should focus on business model components from the right side, that is Customer segment, Relationships, Channels.
3. All quadrants can use the business model components Value propositions, Effects, Revenue streams, Cost structure.

 

 

When you plan the project SWOT, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the work on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card. Don’t forget to work the conclusions from the SWOT exercise back into the material you have created and consider in all the future material.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

4. The Project Business Model Timeline

5. The Project Business Model Sprintlines

Next in the Project Business Model series of posts:

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Sprintlines

This post is the fifth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Sprintlines

When we plan and execute our changes we may end up on levels where people aren’t perhaps used to or see the benefit from working with scrum and agile techniques. On other areas of the solution space (primarily software development) people are used to these agile techniques and practice them with great satisfaction. Our work then is to merge the views of all these people into a planning instrument that can cater for all their ways, so we can have the best from them all.

One way of solving this problem is to pull it together in “sprintlines”. In this case we have within each grey box a planning area containing a first cut product backlog from which each team would create their sprints. We use the word sprintline to refer to the horizontal lines as we have found it easier to connect the detailed planning with higher order planning in this way.

When you plan the project sprintlines, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the work on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card. If possible use rules of thumb from scrum and other methods to correctly size and match the work. Refine the work on scrum boards and whatever other tools are necessary just be sure to aggregate it up to the programme and portfolio levels so we can have an investment view on it all.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

4. The Project Business Model Timeline

Next in the Project Business Model series of posts:

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Model Timeline

This post is the fourth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Timeline

The cue here is that value rises to the top and is released through the yellow date bubbles. If you work in an environment where the appetite for release is higher, then you could add smaller grey/red date bubbles. These grey/red bubbles would contain the outcomes of each sprint as it is related to a result, shown here as red rectangles. (More on sprints in the next post)

When you plan the project timelines work with the result card you created earlier and try to capture the essential release dates from a business perspective. Do the job in a workshop format. Give everyone all the cards created so far and a set of empty timeline cards that they can outline their own view of the projects on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

Next in the Project Business Model series of posts:

5. The Project Business Model Sprintlines

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts