The Digital Business

Digital business top dots

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.

Some basic business capability map patterns (level 0)

Don’t be scared, level zero in a capability map is just a way to structure the map so that we have a consistent way of communicating. It’s really not that important if all you wish todo is create an excellent set of capabilities for your business. However if you are intent on changing the foundation of your business then level zero is absolutely imperative to get right. Capabilities and capability maps are not organization structures, they do however serve as a powerful instrument when one need to create an organization architecture, in fact they are best thought of as organizing structures.

Basic patterns for capability map level 0

Are these patterns better than any other pattern one may ask and the answer is that they are not. There is probably more than a enough patterns to this problem of layout if you Google for capability maps. It’s just that I’ve used these patterns a lot and have seen others use them and have found them to be highly effective to influence the future of a business.

Remember that any business capability map can be reordered into any of these patterns, so do not let the choice of pattern for level zero stop you from investigating what is important.

The system perspective is highly influenced by the viable systems model created by Stafford Beer and the OODA Loop created by John Boyd.

When you should use this

  • Whenever you need to create a capability map
  • Whenever you have a desire to change the business

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • Use the patterns many times to understand what works and refine those
  • Add your own patterns and create a pattern library
  • From a training perspective I’ve found that the hierarchical pattern works best

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

Download
You will be able to download the presentation here.

Related

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

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.

The_Customer_Card

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

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

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

Enterprise Architecture Inquiry

I’ve had this outline of a book project laying dormant on Google drive for a couple of years. The working title was “The Art of Documenting Enterprise Architecture”. I’m not to fond of that title since I wasn’t aiming to document an architecture, rather capture and think through questions one would need answered to get insight into what the enterprise is all about.

There is no guarantee that I’m ever going to finish this post but the thing written a couple of years ago is still valid so I thought I’d publish that part here.

 

Enterprise Architecture Inquiry

yeanyeang

 

Many misread the depiction of the integrated view above. People ask – why is strategy closer to mission than vision? Why is tactic above strategy? To clarify this predicament it should be clear that the order one should read the integrated view above is starting with vision and then ends and then mission and lastly means. That closes the outer iteration and gives guidance to reading the inner iteration which start with goal and then objective and then strategy and lastly tactic.

Table of contents

Section 0 – The Things We Ought To Think About Before We Do Anything Else

Section 1 – The Historic Facts of the Enterprise

Section 2 – The Strategies

Section 3 – The Capabilities

Section 4 – The Business models

Section 5 – The Value flows

Section 6 – The People organisations

Section 7 – The Tactic plans

Section 8 – The Economic models

Section 9 – The Information

Section 10 – The Technologies

Section 11 – The Governance structures

Section 0 – The Things We Ought To Think About Before We Do Anything Else

The world is complicated, it may even be downright complex sometimes. We all know this, but what we don’t always recognise is that we don’t need to bring that into the formulation of the basic questions we seek to answer.

To keep it simple, here is five basic questions:

  1. Are we the right people doing the things we do?
  2. Are we doing the right things?
  3. Are we doing the right things well?
  4. Are we receiving the expected yield?
  5. Are we happy doing the things we do?

Section 1 – The Historic Facts of the Enterprise

The first of many small steps is usually the hardest to take. The second of a thousand steps is barely noticeable. The third of a million steps is forgotten. The last step of any walk determines if you will reach the target, yet the last step is rarely remembered. Any journey started must have an end; it cannot be that we journey without end. Time is the only resource with a direction and it points ever forward. We can only travel through time using our memory as the machine that displays the wonders that has happened before hand. Yet even if we may be at arm’s length in our minds we can still not change that which has happened, best then to plan for the future that has already happened.

Enterprise history

The purpose of these questions is to gather and structure data into what has happened. That data could be used in a diagnosis phase to gain insight into what could possibly be expected in the future from the Enterprise.

Culture

What values lie behind the way the Enterprise operate and to what extent are these values visible on a daily basis?
What cultures are active in the Enterprise today?
What core principles are there?
What behaviours are rewarded in the Enterprise?
How have these cultural components shifted over time?

Owners

Who has owned parts of the Enterprise and to what extent?
Why did they own parts of the Enterprise?
How has the ownership changed during the years and when did that happen?

Events

What events has affected the Enterprise and to what extent?
Why did they affect the Enterprise and how have they changed the Enterprise?

Markets

What markets has been targeted by the Enterprise and what was the outcome?
What was the investment made in those markets?
What was the purpose behind targeting those markets?
What offers/products/services where made to those markets?
What markets has been considered but then not entered into?

Products and services

What have been offered to the markets in terms of products and services?
What was the purpose behind this particular selection and what was the outcome?
Is there products or services created that where later decided against putting on the market and what was the reason behind that decision?

Immaterial

What immaterial rights (IR) have the enterprise held and what IR do they hold today?
What was the purpose behind this particular selection and what was the outcome?
What is the direction on IR today?

Location

What locations have the enterprise operated at?
Where is the enterprise operating today?
What was the purpose behind this particular selection and what was the outcome?

Permits and regulations

Under what permits and regulations have the enterprise operated?
What permits and regulations are in play today?
What was the purpose behind these particular selections and what was be the outcome?

Insurance

What insurances have the enterprise opted for?
What was the purpose behind this particular selection and what was the outcome?

Disputes

What disputes have the enterprise been involved in?
What was the reason behind this particular dispute and what was the outcome?

Agreements

What agreements have been entered into by the enterprise?
Why where they so important and what was the outcome?

Customers

What has been the most important customer segment?
Why where they so important?
What was the outcome for those customer segment?
What customer segments is in play today?

Partners / Suppliers

Who has been the most important partners / suppliers?
Why where they so important?
What was the outcome from those relationships?

Competition

Who have been the most important competitors?
Why where they so important?
What was done to win over them and what was the outcome?

Employees

How many employees have there been over time?
What key skills did they possess?
What was the purpose of having those employees and what has been the outcome so far?

Management

How many managers and managerial roles have there been over time?
What was the purpose of having those managers/roles and what has been the outcome so far?

Board

How many board members have there been?
Who where these board members?
What was the purpose of electing those board members and what has been the outcome so far?

Economic

How has the profit and loss evolved over time?
What was it that effected the P/L to develop like it did?
What revenue streams have the Enterprise had?

 

Section 2 – The Strategies of the Enterprise

Many of us have spoken of strategy and tactics and even more have listened to the words being uttered as a vision for some important change.  Few have given thought to the true meaning of the words and even fewer have tried to alter their use of the words. It should be clear that in this post I refer to a strategy as a description of a way forward, it contains the general characteristics of the path we would like to travel if all unfolds according to plan. A tactic on the other hand is a detailed recollection of the actions and events that follow the course of a strategy.

Strategic concepts

The purpose is to find the questions that would capture the strategy as concepts used in the enterprise.

To be written…

Tactical concepts

The purpose is to find the questions that would capture the tactic as concepts used in the enterprise.

To be written…

Section 3 – 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 we refer to capabilities as the core skills that we must master as a social system (the organisational level).

To be written…

Section 4 – The Business models

To be written…

Section 5 – The Value flows

To be written…

Section 6 – The People organisations

To be written…

Section 7 – The Tactic plans

To be written…

Section 8 – The Economic models

To be written…

Section 9 – The Information

In asking questions about the information we need to look both where we are and where we could be.

What common terms & definitions?
What enterprise information architecture?
What meta data and master data?
Which data management tools?
What data governance structures?

Section 10 – The Technologies

In asking questions about the technologies we need to look both where we are and where we could be.

Which technology stack?
Which applications?
Where use custom development, standard applications, utility services?
Which communication (Integration, Service Orientation…)?
What roadmaps?
Which guiding principles?

Section 11 – The Governance structures

To be written…


 

Post change log

2015-10-27: Published initial post
2015-11-07: Added some questions on technologies and information

 

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

The future for enterprise architects

The rise of the experience economy have brought with it accelerating developments in organizational patterns, business models, software, hardware and algorithms. Taken together it points the way to something new about how the enterprise architecture profession needs changing. The skills of the new ways of working vary, but they are all examples of how the momentum in enterprise architecture must shift away from “theoretical modeling”, “information hoarding” and “static planning”, toward things that truly live in the real world of modern business. In business it all starts with things that we observe, thats future uncertainties, and things that we orient our selves on, thats unfolding factors and things we decide on, thats current situation. The responses we make to these insights are how we act in the real world.

boyd_ooda_small

The illustration is the OODA graphic from Boyd’s 1995 lecture “The Essence of Winning and Losing,” as reproduced and explained by his associate, Dr. Chet Richards, in his book Certain to Win.

The emerging situation requires new ways and the use of new toolsets adapted to the world at hand. One immediate response to the emerging situation is to start continously exploring large sets of cross domain data in solving the complex whole system problems that business execute in. That kind of work requires involvement of people from all areas of business like demographics, politics, markets, environment, sales, marketing, research, finance, legal, management and computer science, and the use of advanced technology. IBM has with its Watson for analytics released services that can be used to analyze cross domain data in a rather intuitive way. Others, like SAP with LumiraSAS with Visual Analytics and Microsoft with Power Bi are all great tools. If you want to dive deeper and get your hands all the way into the source then R and the various tools around that is awesome.

William Gibson said that the future is already here – it’s just not evenly distributed. In the field of enterprise architecture that rings true.

Startup 101 – A great set of resources

On the awesome site Genius.com people have gathered some amazing lectures of starting up a business. The lecturers are some of the most famous and successful people in business today.

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