Architecture for the Digital Business

There’s another metaphorical asteroid approaching the world. The last one (the Web) hit around 1991 and we are still struggling to come to terms with it. But the next one is an order of magnitude bigger – it’s often referred to as Digital Business. It’s not a bad name, but it doesn’t immediately signal some of the awesome impacts that will result. Essentially Digital Business is about Web enabling everything we do. Don’t be fooled into thinking this is about Google Glass, or the Smart Watch. It’s about Web enabling “everything”, from vehicles, power and water meters, appliances, houses, offices, driverless cars to traffic management systems, personal healthcare and anything you can think about. All these nodes become devices using sensors to communicate on a peer to peer basis via Machine to Machine (M2M) networks, and generate vast amounts of data that will revolutionize the way the world works! Like the Web, adoption will be slow at first, but the initial stages are already happening and we can expect it will be another 15 to 20 year change cycle which follows an exponential growth curve.

Don’t believe me? A really good example I just happened to see as I wrote this blog, is the smart bike lock from Lock8. The lock is paired with a mobile app and, lo and behold it’s paired with a peer-to-peer marketplace that a) alerts the owner if someone tries to steal the bike and b) tracks it if the thief manages to take it away, and c) even allows owners to loan or rent their bikes to friends or others registered on the service, and make a little cash on the side. Of course Lock8 also works in lots of other use cases. And just to reinforce the message, Lock8 have been hugely successful in raising significant funding through crowdsourcing!

It’s interesting to observe the media debate about Google Glass, which is strongly focused on privacy issues. Yet there is little or no debate yet about the Web enablement of almost everything, which has far more implications, not just for privacy, but also security, reliability and risk, as well as impacts on employment and changes in long established cost assumptions. It’s likely that Digital Business will trigger huge cultural changes. And that’s before you get to talk about humanoid robots to do our housework, look after children and older citizens. And yes they are coming also.

So what’s happening to the archetypal enterprise in this process of change. And what does enterprise architecture look in this changing environment? Of course technology is the primary stimulus, but we need to look at the social and economic effects of new technology enabled capabilities to understand how the enterprise may respond.

By coincidence I noted the Drucker Form met last month in Vienna and one of their major topics was Complexity. And there was fascinating debate about what complexity is, and whether it is increasing over time. And surely the Digital Business with the expected exponential growth in nodes, information and dependencies is going to be a major driver of complexity increase.

Roger Martin, of the University of Toronto, told the forum that one reason we feel overwhelmed by complexity . . . is because of a growing tendency to see and study problems within silos. The complexity of our world has actually not increased. It is just the unaddressed “inter-domain complexity” which makes us feel like everything has become more complex.

Don Tapscott, (of New Paradigm) was clearly responding to this issue of inter-domain complexity when he told the  conference – first, our institutions need to radically decentralize. Further, the future is not to be predicted, but to be achieved through a new dynamic paradigm including self-organizing, emergent and sometimes resilient networks involving millions of stakeholders. These networks embrace, active participation, uncertainty and constantly changing conditions, and they show great promise for solving global problems and governing an volatile and complex planet in the future. Command and control being replaced with self-organizing networks. Linear and non-linear organizations.

I particularly liked Tapscott’s analogy of murmurations of flocking starlings. Starlings somehow organizing themselves en masse to see off predators are at the opposite end of the (command and control) leadership spectrum from the arch bureaucrat. It reminds me also of the March of the Penguins. Did you ever see the huddle of thousands of penguins, their backs to the ice cold wind, continuously moving inwards and then outwards to allow all the group members to share the extreme exposure and protect the inner circle.

And of course this is what’s happening today. Self-organizing networks are forming everywhere, facilitated by the Web, and enabling collaboration and information sharing and transactions on a local and global scale without any central command or control.

So what does the Enterprise model of the future look like? In the diagram below I suggest the enterprise is a network of networks, a series of Capabilities that are supporting many Networks. The scope of the enterprise is the extent of interest in the Networks and Capabilities, not the boundaries of the enterprise as a legal entity. Participants are of course any form of Node, Device, Person, Entity that has a relationship with the Capability through some form of Experience and /or Channel. That Experience is provided by one or more Solutions, but we should plan that distributed Capabilities collaborate to share common assets on many levels. Note this is a very high level diagram, and you can safely assume that all the relationships are many to many. Further there is much more detail that is required particularly to make this a business AND IT model. But it is sufficient for my purpose in showing a core enterprise.

So what does the Enterprise Architecture look like in the fully distributed, self-organizing enterprise. The diagram below shows that the new EA needs to establish the basis for the federated business with architectures that are about managing the interconnections and dependencies, while allowing the distributed business to have as much freedom of action as is possible. The Reference Architecture , therefore defines the minimum necessary alignment. The Platform Architecture manages the essential business and IT interoperability and consistency that ensures the federation has minimum necessary cohesion. The Common Asset Architecture is then a portfolio of pluggable service components – that comply with the platform and facilitate sharing of common behaviors where appropriate, and enable solutions that have the necessary level of enterprise consistency together with required level of localization. Each of these architectures of course has the five views – Business, Service and Application, Implementation, Technology and Deployment. But this is a Federated Enterprise Architecture, that’s purpose is not to exert command and control over the leaf nodes, rather to facilitate the minimum necessary consistency to ensure the enterprise is a) in regulatory compliance and b) able to optimize cross enterprise dependencies, information and customer experience.

 In the Digital Business world Enterprise Architecture is vital, but it needs to be tightly focused on optimizing the distributed, federated business work, which means delegation. And here we have another cultural problem, because we have to embrace subsidiarity, the notion that all matters ought to be handled by the smallest, lowest or least centralized authority capable of addressing that matter effectively. And in general we are very bad at subsidiarity. Enterprises tend to prefer command and control as the default modus operandi.

The diagram below suggests that EA needs to undergo a significant transformation, moving from the As-Is in which the objective is frequently to seek the highest level of commonality to a To-Be model in which the aim is to organize the business as independent capabilities. Clearly this is much more than an architecture issue. It must be reflected in the way the business and IT are organized, transferring and delegating responsibility to leaf nodes, while establishing and governing the key policies that make the enterprise a coherent whole.

In my experience many enterprises have frequently responded to Web based business opportunities in a tactical, technology led manner. This has led to duplication of core business capabilities and, I observe, critical weaknesses in customer experience and lost opportunities. Many enterprises particularly telecos, publishers, video stores, music and media firms, have through competitive pressure come to recognize the strategic importance of the Web. In embracing the Digital Business, enterprises may be tempted to go down the tactical route, but this is likely to be a big mistake, as the network effect will become an integral part of the enterprise’s product and services.

It’s true that Asteroids don’t hit the earth very often, and when they do the impact is immediate and very dramatic. Digital Business isn’t going to be instantaneous, but the impact is likely to be colossal.  So the key message is – figure out your new reference model, get rid of command and control, but manage the cross network dependencies at all levels of the reference architecture – that’s how you deliver real agility in the new world.

References
Drucker Forum
Lock8
Links:
Blogpost: Agile Architecture
CBDI Journal Report: Capability Planning and Analysis

Architecture for the Digital Business

There’s another metaphorical asteroid approaching the world. The last one (the Web) hit around 1991 and we are still struggling to come to terms with it. But the next one is an order of magnitude bigger – it’s often referred to as Digital Business. It’s not a bad name, but it doesn’t immediately signal some of the awesome impacts that will result. Essentially Digital Business is about Web enabling everything we do. Don’t be fooled into thinking this is about Google Glass, or the Smart Watch. It’s about Web enabling “everything”, from vehicles, power and water meters, appliances, houses, offices, driverless cars to traffic management systems, personal healthcare and anything you can think about. All these nodes become devices using sensors to communicate on a peer to peer basis via Machine to Machine (M2M) networks, and generate vast amounts of data that will revolutionize the way the world works! Like the Web, adoption will be slow at first, but the initial stages are already happening and we can expect it will be another 15 to 20 year change cycle which follows an exponential growth curve.

Don’t believe me? A really good example I just happened to see as I wrote this blog, is the smart bike lock from Lock8. The lock is paired with a mobile app and, lo and behold it’s paired with a peer-to-peer marketplace that a) alerts the owner if someone tries to steal the bike and b) tracks it if the thief manages to take it away, and c) even allows owners to loan or rent their bikes to friends or others registered on the service, and make a little cash on the side. Of course Lock8 also works in lots of other use cases. And just to reinforce the message, Lock8 have been hugely successful in raising significant funding through crowdsourcing!

It’s interesting to observe the media debate about Google Glass, which is strongly focused on privacy issues. Yet there is little or no debate yet about the Web enablement of almost everything, which has far more implications, not just for privacy, but also security, reliability and risk, as well as impacts on employment and changes in long established cost assumptions. It’s likely that Digital Business will trigger huge cultural changes. And that’s before you get to talk about humanoid robots to do our housework, look after children and older citizens. And yes they are coming also.

So what’s happening to the archetypal enterprise in this process of change. And what does enterprise architecture look in this changing environment? Of course technology is the primary stimulus, but we need to look at the social and economic effects of new technology enabled capabilities to understand how the enterprise may respond.

By coincidence I noted the Drucker Form met last month in Vienna and one of their major topics was Complexity. And there was fascinating debate about what complexity is, and whether it is increasing over time. And surely the Digital Business with the expected exponential growth in nodes, information and dependencies is going to be a major driver of complexity increase.

Roger Martin, of the University of Toronto, told the forum that one reason we feel overwhelmed by complexity . . . is because of a growing tendency to see and study problems within silos. The complexity of our world has actually not increased. It is just the unaddressed “inter-domain complexity” which makes us feel like everything has become more complex.

Don Tapscott, (of New Paradigm) was clearly responding to this issue of inter-domain complexity when he told the  conference – first, our institutions need to radically decentralize. Further, the future is not to be predicted, but to be achieved through a new dynamic paradigm including self-organizing, emergent and sometimes resilient networks involving millions of stakeholders. These networks embrace, active participation, uncertainty and constantly changing conditions, and they show great promise for solving global problems and governing an volatile and complex planet in the future. Command and control being replaced with self-organizing networks. Linear and non-linear organizations.

I particularly liked Tapscott’s analogy of murmurations of flocking starlings. Starlings somehow organizing themselves en masse to see off predators are at the opposite end of the (command and control) leadership spectrum from the arch bureaucrat. It reminds me also of the March of the Penguins. Did you ever see the huddle of thousands of penguins, their backs to the ice cold wind, continuously moving inwards and then outwards to allow all the group members to share the extreme exposure and protect the inner circle.

And of course this is what’s happening today. Self-organizing networks are forming everywhere, facilitated by the Web, and enabling collaboration and information sharing and transactions on a local and global scale without any central command or control.

So what does the Enterprise model of the future look like? In the diagram below I suggest the enterprise is a network of networks, a series of Capabilities that are supporting many Networks. The scope of the enterprise is the extent of interest in the Networks and Capabilities, not the boundaries of the enterprise as a legal entity. Participants are of course any form of Node, Device, Person, Entity that has a relationship with the Capability through some form of Experience and /or Channel. That Experience is provided by one or more Solutions, but we should plan that distributed Capabilities collaborate to share common assets on many levels. Note this is a very high level diagram, and you can safely assume that all the relationships are many to many. Further there is much more detail that is required particularly to make this a business AND IT model. But it is sufficient for my purpose in showing a core enterprise.

So what does the Enterprise Architecture look like in the fully distributed, self-organizing enterprise. The diagram below shows that the new EA needs to establish the basis for the federated business with architectures that are about managing the interconnections and dependencies, while allowing the distributed business to have as much freedom of action as is possible. The Reference Architecture , therefore defines the minimum necessary alignment. The Platform Architecture manages the essential business and IT interoperability and consistency that ensures the federation has minimum necessary cohesion. The Common Asset Architecture is then a portfolio of pluggable service components – that comply with the platform and facilitate sharing of common behaviors where appropriate, and enable solutions that have the necessary level of enterprise consistency together with required level of localization. Each of these architectures of course has the five views – Business, Service and Application, Implementation, Technology and Deployment. But this is a Federated Enterprise Architecture, that’s purpose is not to exert command and control over the leaf nodes, rather to facilitate the minimum necessary consistency to ensure the enterprise is a) in regulatory compliance and b) able to optimize cross enterprise dependencies, information and customer experience.

 In the Digital Business world Enterprise Architecture is vital, but it needs to be tightly focused on optimizing the distributed, federated business work, which means delegation. And here we have another cultural problem, because we have to embrace subsidiarity, the notion that all matters ought to be handled by the smallest, lowest or least centralized authority capable of addressing that matter effectively. And in general we are very bad at subsidiarity. Enterprises tend to prefer command and control as the default modus operandi.

The diagram below suggests that EA needs to undergo a significant transformation, moving from the As-Is in which the objective is frequently to seek the highest level of commonality to a To-Be model in which the aim is to organize the business as independent capabilities. Clearly this is much more than an architecture issue. It must be reflected in the way the business and IT are organized, transferring and delegating responsibility to leaf nodes, while establishing and governing the key policies that make the enterprise a coherent whole.

In my experience many enterprises have frequently responded to Web based business opportunities in a tactical, technology led manner. This has led to duplication of core business capabilities and, I observe, critical weaknesses in customer experience and lost opportunities. Many enterprises particularly telecos, publishers, video stores, music and media firms, have through competitive pressure come to recognize the strategic importance of the Web. In embracing the Digital Business, enterprises may be tempted to go down the tactical route, but this is likely to be a big mistake, as the network effect will become an integral part of the enterprise’s product and services.

It’s true that Asteroids don’t hit the earth very often, and when they do the impact is immediate and very dramatic. Digital Business isn’t going to be instantaneous, but the impact is likely to be colossal.  So the key message is – figure out your new reference model, get rid of command and control, but manage the cross network dependencies at all levels of the reference architecture – that’s how you deliver real agility in the new world.

References
Drucker Forum
Lock8
Links:
Blogpost: Agile Architecture
CBDI Journal Report: Capability Planning and Analysis

Businesses Banking on Breakthrough Innovation

Post co-authored by Rob Shelton, PwC’s Global Innovation Strategy Leader Last year if you asked a CEO what he or she is doing to achieve growth, the answer would have been investing in China. This year the answer is innovation. Business executives are banking on bold innovation to meet aggressive growth targets, so they are taking innovation more seriously than ever before. In the spirit of Peter Drucker who said, “innovation is work,” business executives […]

The Business Capability Manager

I am excited about Accelare’s new software product: The Capability Manager. Accelare has announced the general availability of the WhatFirst™ Capability Manager, a new tool for creating and managing business capability models, built on the Microsoft SharePoint 2013 platform. WhatFirst™ Capability Manager is designed as a simple to acquire, simple to learn, simple to use […]

The Business Architect’s Skill Set

Last week I taught a half-day workshop on Kick-starting Business Architecture at the 2013 Building Business Capability conference in Las Vegas. I had 75 participants from a wide variety of backgrounds including business architects, business analysts, enterprise architects, project managers, business process managers, business managers, and strategists. A very diverse group to say the least. […]

Models and reasoning-processes in enterprise-architecture

Just how should we use models and frameworks in enterprise-architectures – particularly in the exploratory phases of architecture-development? What’s the best way to use them? And how do we prevent the frameworks from constraining our options in those processes? These

Mapping vs. Modeling

What are the differences between them and when to use each technique? If we think about maps the most familiar to us is possibly the road map. Then if we put multiple maps together we can create a road atlas. These are great for allowing us to see where we are and where we might […]

Related posts:

  1. Business Architecture 101 – It’s results that count! Business Architecture may not be a new term, but it…
  2. Mass Modeling Process discovery and process validation are interesting topics and ones…
  3. The Reality of Process Excellence Whether we like to admit it, most organizations are still…

Related posts brought to you by Yet Another Related Posts Plugin.

What makes models interesting

Since 2009, when I first published my open source metamodel of enterprise architecture (the Enterprise Business Motivation Model), I’ve had numerous conversations with architects, business analysts, consultants, technologists, and the occasional student about models.  I frequently hear things like “I have an update to your model that makes it better,” to which I reply “cool, let’s see it.”

After seeing about a dozen now, I’ve begun to realize that I need to ask better questions.

Some models are simply more interesting than others.  Some have relationships that are more appropriate for specific situations.  (for example, one friend sent me his version of my model with specific elements related to government organizational structures and interrelationships).  That is very interesting, because I can see a value in capturing distinctions related to different types of organizations.  Another friend sent me an update to my model with greater focus on customer relationships, which is great if the goal is to highlight the importance of customer-first modeling.  Another person sent me an extension he did to Osterwalder’s model to include additional aspects needed to develop a business that is sustainable in the world environment.

Those are the good examples.  They add unique value.  They consider new things.

Some not-so-interesting examples often come from students or usually young architects (less then three years in field), who simply feel that one set of relationships is “better” than another, without any particular rationale other than “it looks better to me.”  Note: that’s fine.  It means the model represents their way of thinking, and their use of terminology.

But what do I say when they expect me to rewrite the EBMM to match their thinking processes?

I say “yes” in very narrow circumstances.

So for those folks who want to propose an alternative model or an update to the EBMM, let me lay out some basic concepts and guidelines.

Prove that the model extension answers questions that need to be answered

The first and foremost problem is a simple one: adding stuff just because we can.

The EBMM can certainly be “bigger” if that were my goal.  But it isn’t my goal.  My goal is to ask specific questions and produce a model that answers them.  The list of questions is far more interesting than the model itself. 

So before you send me a model, send me the list of questions you need to answer with that model.  THINK ABOUT IT.  Don’t create the model and then go hunting for questions that justify it.  These need to be legitimate questions that are of demonstrable concern or value to an enterprise-level stakeholder. 

The EBMM was designed to answer a specific set of questions.  Those questions are included in the model itself.  If you want to extend the EBMM, ask different questions.  Then, we can extend the model to answer them if necessary. 

“All models are wrong.  Some models are useful.” 

Many of us are already familiar with this quote, from George Box, noted British statistician and author.  While he was referring to statistical models, his advice is worth considering on a deeper level.  In his 1976 article, Science and Statistics, he provided a very useful bit of advice to the would-be creator of models. 

“Since all models are wrong the scientist cannot obtain a “correct” one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity.” (Journal of the American Statistical Association, 1976, http://www.jstor.org/stable/2286841,  retrieved 26 Sept 2013)

George Box said that so much better than I would have.  While he was referring to science and statistics, his advice applies to Enterprise Architecture rather well. 

What it means is this: if you have two models, both that capture the USEFUL elements needed to describe something, and one is simpler than the other, go simple.  In other words, I don’t care what is “correct.”  I care what is useful. 

Be forewarned: you send me a model that is a more detailed elaboration of my own model, with more elements and more relationships but which does not capture USEFUL knowledge more clearly, or convey information in a more accurate manner, I will reject it.  Additional detail is not useful unless you can demonstrate value. 

In order to demonstrate value, you need to show me two sets of information: one captured in the existing model and one captured in your more elaborate model.  You then need to describe to me how that information, in context, is less useful the way I captured it, and more useful the way you captured it.   Then, I will add complexity to the EBMM.  Yes, it’s a high bar.  The EBMM is complex enough as it is.

On the other hand, if you send me a model and you can demonstrate that you can use fewer elements to capture knowledge or describe intent than I did, I will not only listen, I’ll probably take a swing at removing stuff from the EBMM.  That’s a much lower bar for you, and a high bar for me.  I need to prove to myself (and you, if you are willing to put up with me) that the complexity in the EBMM is justified.  I will make things as simple as possible, but no simpler.

Simplicity in practice

Many folks have asked me why the EBMM doesn’t have entities for “database” or “network node” (or name your IT entity-of-the-day).  “It’s not a complete Enterprise Architecture model”, is the usual cry.  I usually point out that they are not looking at the right viewpoint.  The primary viewpoint, which most people are aware of, doesn’t show every element.  On the other hand, the IT Traceability viewpoint (below) has all the technical elements that an enterprise architect needs to model the technology landscape at an architectural level. (click the image to enlarge).

IT Traceability Viewpoint 4.1

Simplification one: the model is for Enterprise Architects, not IT management

But wait, they cry, where’s the entity for a database!  Where’s the SharePoint Server (or the active directory server or the service bus, yada yada yada). 

Challenge accepted.  In the metamodel view above, information is managed within the context of an application.  Prove to me that you need to illustrate the element that gives you heartburn in a different way than I have captured.  Consider two questions: (a) Can an existing element be used? or (b) Is that element relevant in an enterprise architecture setting?

I can consider SQL Server, BizTalk, SharePoint, SAP, Dynamics, and many other systems to be “platforms” to be used by applications.   I can consider a server to be a “host” but I can also consider entire environments (like a DMZ or even the Azure cloud) as a host.  

So, no, I don’t have elaborate details that go further “down the stack” to the point of illustrating network nodes, because I don’t need them.  IT management does need those details.  That’s what a Configuration Management Database (CMDB) is for.  The EA repository may overlap with the CMDB but these two critters are quite distinct.  (topic for another post).

Simplification two: the model minimizes transitive relationships

A transitive relationship is of the form

A relates to B, B relates to C, therefore A relates to C.

I want to see the relationships between A and B, and between B and C. 

However, if you send me a model, please be aware of your transitive relations.  Don’t ILLUSTRATE the relationship between A and C unless it is NOT easily derived.  For example, look at the diagram above.  We could say that a Business process demands a system interaction point.  A system interaction point is described in a use case or user story.  Therefore, the relation between a business process and a use case can be easily derived.  Note, however, there is no “relationship arrow” on the model.  It is transitive, so there is no need to add the relation.

Minimizing transitive relationships reduces the complexity of the model substantially.  Realize that this is a conceptual model.  Nearly all concepts can be described using transitive relations (and many are). Rather than have a model where “everything relates to everything,” this simple practice makes the model readable and usable. 

On the other hand, some transitive relationships should be captured.  These would be the relationships that are NOT easily derived because of their complexity or underlying meanings.  For example, in the diagram above, an application uses a platform, and a platform is deployed on a host. I also illustrate the transitive relation (application is deployed on host).  Why?  Because platforms are optional.  It is possible to create an application that is NOT on a platform.  However, the relationship to a host is not optional.  Since this detail is not easily derived from observing the model, I illustrated both relations. 

Important note: when I discuss business capabilities, I say things like “you should map people, process, tools and information” yet in the model, I only illustrate the connections between the capability and process, and capability and tools.  That’s because the relation between capability and people is transitive (through process).  The relation between capability and information is similarly transitive (also through process).  I follow my own rules. 

Conclusion

For those folks kind enough to offer feedback on the Enterprise Business Motivation Model, I want to say, first and foremost, thank you.  I listen to every opinion and I care about every detail.  It is a labor of love.  Each new insight offers me an opportunity to refine the model, and I may make changes simply because you taught me something.

That said, if you are focused on seeing a change to the model as a result of your research, I will expect you to be cognizant of the context and concepts expressed in this blog post.  I certainly will be.

Categories Uncategorized

Defining Business Architecture

Business Architecture is a burning hot topic these days. I believe it is a key enabler to get us to a more contemporary or new world of Enterprise Architecture (EA). Continuing the shift from an IT centric Enterprise Architecture to…

Categories Uncategorized