Aggregated enterprise architecture wisdom
An Enterprise Architecture, by the time is becomes useful to the business, has consumed considerable time and effort to develop and populate. Often the principle deliverable of an Enterprise Architecture specific or Transformation Project the transition to a ‘Business As … Continue reading →
The architecture of an application is often evaluated by assessing its quality attributes; things like performance, security, maintainability and availability. One topic that often surfaces is whether Usability should be considered an architecture…
“The world still reels from the fallout from the crisis of 2008 :: Who will lead us out of our uncertainty?” Those are the frame-captions for a cartoon-style advert that’s currently running on the Forbes website, for an upcoming conference…
The term “Black Swan” was coined by University of Oxford, Saïd Business School professor Nassim Nicholas Taleb to describe high-impact events that are rare and unpredictable but in retrospect seem not so improbable. In the world of IT, black swan projects reap catastrophic effects and even result in a complete corporate meltdown. According to Taleb’s colleagues, Bent Flyvbjerg and Alexander Budzier, “IT projects are now so big, and they touch so many aspects of an organization, that they pose a singular new risk.”1 Flyvbjerg and Budzier go on to state “The CEOs of companies undertaking significant IT projects should be acutely aware of the risks. It will be no surprise if a large, established company fails in the coming years because of an out-of-control IT project. In fact, the data suggest that one or more will.”
They reached this bleak conclusion after conducting the largest global study ever of IT change initiatives. The pair examined 1,471 projects, comparing their budgets and estimated performance benefits with the actual costs and results. The IT change initiatives ran the gamut from enterprise resource planning to management information and customer relationship management systems. Their study sample drew heavily on public agencies (92%) and U.S.-based projects (83%), but they found little difference between them and projects at the government agencies, private companies, and European organizations that made up the rest of their sample.
When the University of Oxford team broke down the projects’ cost overruns, what they found surprised them. The average overrun was 27% — but that figure masked a far more alarming one. Graphing the projects’ budget overruns revealed a “fat tail” — a large number of gigantic overages. Fully one in six of the projects they studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.
Their findings highlighted the true pitfall of IT change initiatives: It’s not that IT projects are particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of IT projects incur massive overages — that is, there are a disproportionate number of Black Swans. By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real problem.
According to University of Oxford researchers, any company that is contemplating a large technology project should take a stress test designed to assess its readiness. Leaders should ask themselves two key questions as part of IT black swan management: First, is the company strong enough to absorb the hit if its biggest technology project goes over budget by 400% or more and if only 25% to 50% of the projected benefits are realized? Second, can the company take the hit if 15% of its medium-sized tech projects (not the ones that get all the executive attention but the secondary ones that are often overlooked) exceed cost estimates by 200%? Though these numbers may seem comfortably improbable, their research showed they occur with uncomfortable frequency.
Even if a company passes the stress test, smart managers need to take other steps to avoid IT black swans. They should consider breaking big projects down into ones of limited size, complexity, and duration and make contingency plans to deal with unavoidable risks.
That’s where Enterprise Portfolio Management (EPM) comes in to help. By leveraging EPM techniques, CIOs can take a step back, see the bigger picture and truly understand how IT resources are spread across and utilized by the business. An EPM approach can help CIOs, CFOs and CEOs assess what they have in terms of Applications, Technologies, Information and Projects/Investments. It can then connect these assets back to and support key business capabilities as well as corporate goals and strategies. An EPM effort can show decision-makers what Applications, Technologies, Information and Projects are needed, which are not, and how to safely retire the assets or cancel the projects that do not provide value to the business. This level of visibility equips enterprise leadership with the ability to make well-informed investment and divestment decisions and helps them avoid becoming another example of good IT intentions that turn into an infamous IT Black Swan.
1. Bent Flyvbjerg and Alexander Budzier, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review. Vol. 89 (2011), No. 9, pp. 23-25.
There is a contradiction that shows up in many books and articles on agile software development. . And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.
Before I begin my rant, I’d like to tell you where it comes from. I am an Enterprise Architect. I am also an agilest. I am a certified Scrummaster (for many years) and have been on many agile projects. I’ve seen success, and I’ve seen failure. I know that agile is good, but not good enough to overcome people who are determined to undermine change.
I am currently engaged on a project to help an organization rewire their business processes. All of their core processes. Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc). I see it all, not just the software engineering bits.
To make this work, we created a set of principles that we use to drive the conversation around transforming the company. We train people on the principles. We connect change to the principles. The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto.
One is focused heavily on the notion of an empowered team. As the trainer, I’ve embedded these principles into my head. Kinda hard not to. So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out. Big time.
And hence the rant. I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams. And I went off. The rest of this post is my rant.
—
On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training. On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service. The net result: we are empowering developers to perform every role. No one else is empowered. They are, in fact, not trusted at all.
At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.
But they are not.
Organizations intentionally create specific roles and groups of people. Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties. The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer. Motivation matters. If you are not motivated to excellence, you will not perform with excellence.
While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well. In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems. Those processes can be performed just fine with motivated people who are trained and experienced in those activities. However, to empower a team, people in these roles must be respected as well.
Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.
For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers. In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed. From those roles, the stories will be drawn. The following is a quote from the book:
To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards. It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary. As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. — “User Stories Applied” by Mike Cohn
I’m an agilest, and this statement takes my breath away. Why? Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have. Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room! At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).
The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization. We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis? It’s a total lack of understanding of the value of roles, and it is a bias that works against success.
Roles are not boundaries. In any team, there are roles. More importantly, as a member of a team, I have to trust my team members to fulfill their roles well. If they need help, I TRUST THEM TO ASK FOR HELP. When they do, I am happy to “cross roles” and provide help. When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role. (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)
Roles are empowering. If my team member does not ask for help, I trust each one to perform his or her role with excellence. If I don’t trust them, how can they develop the excellence that the company expects? How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present?
Roles demonstrate respect. As an agilest, I value people over processes. That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute. I will do so by allowing them to do their work without the “supervision and assistance” of a developer.
If they need me, they will ask for me. Until then, I will get to doing what I do best. I have a job to do, after all… and it is mine to do well.
Agile software development solves a problem. The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality.
If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes. We are, in fact, replacing one kind of waste with another.
Flexibility and agility are terms used almost interchangeably these days as attributes of IT architectures designed to cope with rapidly changing business requirements. Did you ever wonder if they are actually the same? Don’t you have the feeling that these terms remain abstract and without a concrete link to the design of an IT architecture? … Continue reading →
Establishing an Enterprise Architecture to support a business can be likened very much to solving a jigsaw. The jigsaw in question is made up of pieces from multiple puzzles that have been sourced from many different parts of the business … Continue reading →
<p>In an earlier posting we addressed <a href=”http://www.bizzdesign.com/blog/7-applications-of-the-business-model-canvas/”>7 applications of the Business Model Canvas</a>. Sure, we can agree that the Business Model Canvas is very useful for establishing, evaluating and reinventing businesses. But we should not only highlight the countless possibilities of it for a single enterprise. We need to synthesize our understanding of Value Chains and the Business Models and look for the next level of analysis: Value Networks.</p><p>In this blog we will highlight a less addressed aspect from the Business Model Canvas that is rooted in Value Network thinking. There are multiple methods and even tools that support the analysis of Value Networks which is regarded as the collaborations, interactions, and exchanges between business actors. You might have heard or read about <a href=”http://www.amazon.com/Mobile-Service-Innovation-Business-Models/dp/3540792376″ target=”_blank”>STOF</a> and <a href=”http://e3value.few.vu.nl/” target=”_blank”>e3-value</a>. But apart from academic research, Value Networks are less represented in practical settings today. Why? Because of the rapidly increasing complexity of Value Networks – soon we lose track when we think about relations between multiple actors involved in our business such as suppliers, customers, governments, partners, NGO’s. Therefore in this blog we will explain how the simplicity of Business Model Canvas can be used to highlight Value Networks. We discuss an external network approach as well as a more internally oriented network approach.</p><h3>The network is the challenge</h3><p>Imagine a pension fund with three business units – one for asset management, one for customer advice and a third one for customer relationship management and administration – that attempts to broaden its service offerings. We can use the Business Model Canvas to guide this effort. First, we establish the pension fund’s current Business Model Canvas. Then we formulate our goal – which is to broaden the current service offerings. Step by step we elaborate desired Business Model Canvases that include different new service offerings. Finally we selected the most feasible Business Model Canvas for implementation. Business as usual – except that until now we have limited ourselves to only the Business Model Canvas of the pension fund.</p><div class=”captionImage leftAlone” style=”width: 561px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/business-model-canvas-pension-fund.png” alt=”Business Model Canvas pension fund” title=”The main goal is to reach our customers, provide them with our value proposition, and get paid” width=”561″ height=”417″/><p class=”caption”>three main elements of the business model canvas: key partners, enterprise and customers</p></div><p>Although external elements like key partners (1) and customers (3) are included in the Business Model Canvas, at the end of the story the emphasis is on the business model of a single enterprise (2). It seems that key partners are just there to be included in our Business Model Canvas. We also take customers for granted. The main goal is to reach our customers, provide them with our value proposition, and get paid.</p><p>Today more than ever, an isolated view on an organization is not feasible. We are not suggesting that the Business Model Canvas only provides an isolated view. Instead, we want to add some additional support to the Business Model Canvas to broaden and deepen its application from the perspective of Value Networks. This support comes in the form of a Networked and an Aggregated Business Model Canvas.</p><h3>The chained network approach</h3><p>Lets think about the pension fund example again. In addition to the single enterprise view of the Business Model Canvas we should also consider the canvases of our partners and customers for broadening our service offerings. That way we will be able to highlight the interactions of the pension fund and its actors for the sake of the pension fund and its actors –so basically focusing on the Value Network instead of a single company in order to retrieve additional insights that might not be highlighted through a single Business Model Canvas.</p><p> </p><div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600210-canvases-of-partners-and-customers.png” alt=”chained network approach” title=”Does the entire Value Network benefit from newly offered services of the pension fund?” width=”600″ height=”210″/><p class=”caption”>consider the canvases of our partners and customers for broadening our service offerings</p></div><div class=”captionImage leftAlone” style=”width: 561px;”><div class=”captionImage leftAlone” style=”width: 561px;”><span style=”font-size: 11px;”>By representing the Value Network through Networked Business Model Canvases we could answer new questions like: How can we broaden our service offerings through the current Value Network? What improvements can we implement? Does the entire Value Network benefit from newly offered services of the pension fund?</span></div></div><p>Now we are able to involve our partners as well and benefit as a group from the applications of the Business Model Canvas by:</p><ul><li>considering the potential improvement for all value network actors;</li><li>identifying (un)equal distributions of risks, costs and profits for actors based on changes in the value network;</li><li>and using the capabilities and knowledge of all actors to improve the value network;</li><li>Address opportunities of <a href=”http://en.wikipedia.org/wiki/Disintermediation” target=”_blank”>disintermediation</a> concerning removal of intermediaries from a value chain;</li><li>Apply (elements of) the unbundling pattern (page 62), concerning specialization. In commoditizing markets successful organizations focus on either Product Innovation, Customer Relationship Management or Infrastructure Management. Also see <a href=”http://www.amazon.com/Discipline-Market-Leaders-Customers-Dominate/dp/0201407191″ target=”_blank”>Tracy & Wiersema’s value disciplines</a> and <a href=”http://en.wikipedia.org/wiki/Porter_generic_strategies” target=”_blank”>Porter’s generic strategies</a>.</li></ul><h3>The aggregated network approach</h3><p>In addition to a networked Business Model Canvas we can also establish an aggregated Business Model Canvas for the pension fund. Think about the individual business units that are part of the pension fund. While customers may perceive the pension fund as one entity, business units could be independent in terms of their financial performances. Each business unit operates independently and is responsible for own results and achievements. However, because all business units are part of the same pensions fund, the might be using each other’s assets, serve similar customers and share similar partners. Actually a customer could be advised by one business unit on his savings and investment plans, while the same investments could be managed by the assets management business unit. Along the process the customer wants to experience being served consistently by one organization – the pension fund – instead of separate business units. Providing such consistency is obviously important for the pension fund and its business units. But how can they start addressing related issues? And all business units have other internal and external customers as well….</p><p>That is when the aggregated Business Model Canvas comes into play. First we need to establish the individual Business Model Canvases of the pension fund and its business units. Then we need to examine the relations between building blocks across the network by connecting the Business Model Canvases.</p><p> </p><div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600219-Aggregated-Business-Model-Canvas.png” alt=”aggregated Business Model Canvas” title=”Along the process the customer wants to experience being served consistently by one organization instead of separate business units” width=”600″ height=”219″/><p class=”caption”>The aggregated business Model Canvas asks more questions</p></div><p>Again this allows us to answer additional questions like: How can we improve our corporate business model? Is each business unit aligned properly with the corporate organization? What similar partners are used by the different business units? Do we collaborate sufficiently to provide consistent service quality to our customers? Where are opportunities for synergy?</p><p>Now we are able to understand our internal model and consider our business models as complementary parts of the same aggregated model. Benefits of applying this internal network approach are:</p><ul><li>Aligning the whole with its parts</li><li>Learn from each other: using the capabilities and knowledge of all actors to improve the network</li><li>Understand and learn how costs and value creation are distributed throughout the organization in more detail then seen when only creating an enterprise view</li><li>identifying (un)equal distributions of risks, costs and profits for business units based on changes in the value network;</li><li>Understand and manage differences in the business unit’s business models</li><li>Understand and benefit from synergies between the different business models</li></ul><h3><span style=”color: #e3004a; line-height: 14px;”><span style=”color: #e3004a;”><span style=”line-height: 14px;”>Conclusions and advice for applying business model networks in practice</span></span></span></h3><p><span style=”color: #e3004a; line-height: 14px;”><span style=”color: #e3004a;”><span style=”line-height: 14px;”> </span></span></span>Supported by the alternative application suggestions of het Business Model Canvas discussed above, we recommend you to:</p><ol><li>Establish your current business model canvas</li><li>Establish the business model canvases of your internal and external customers</li><li>Establish the business model canvases of your internal and external partners and suppliers</li><li>Interconnect and aggregate the business model canvases</li><li>Assess the effectiveness of the network in term of experienced pain and gain by each partner</li><li>Elaborate opportunities to improve the networks performance as a whole</li><li>Work out these opportunities by following each dependency relation through the network, taking into account pains and gains addressed by each actor in the network</li><li>Establish an integrated implementation plan for the whole</li><li>Establish detail implementation plans for each partner</li></ol><p>Whether the additional Business Models concern internal or external customers and partners, in both cases you will benefit from the additional insights – you will improve your understandings of your own business model as well as the business models of your stakeholders and together you will be able to identify improvement opportunities in your value network. At the end of the day no business operates on its own. Every organization has to collaborate to different extends with multiple actors. Trends that are already here to stay, and trends that should be on your agenda today, all underline the importance of collaboration and require insight in your network. Supply chain management, co-creation, open innovation, knowledge sharing, social enterprise, big-data, predictive analytics.<br/><strong><em>“Understanding your business model is only a first step in understanding your value network.”</em></strong></p><p>We look forward to helping you achieve your goals in the new, networked, normal!<br/>BiZZdesign organizes <a href=”http://www.bizzdesign.com/training/business-model-management/”>training on Business Model Innovation</a> in London (UK), Brussels (BE) and Amersfoort (NL – <a href=”http://www.bizzdesign.nl/training/business-model-management/”>see our Dutch website</a>). More about BiZZdesign’s Business Model Management services, examples and a reference to recent webinars on this subject can be found <a href=”http://www.bizzdesign.nl/consultancy/business-model-management/”>here</a>. Feel free to download the <a href=”http://www.bizzdesign.com/tools/business-model-canvas-module/”>free trial version of our Business Model Canvas tool</a> from our website.</p><p> </p><p> </p>
If you have ever had a debate about whether your organisation should use cloud computing then a discussion of the risks of cloud computing will have been a significant part of it. In doing so, we often fall into a simple logical trap. Cloud computing is just one of the options that we have. The […]
These are dark times, let’s face it. We’re still deep in the worst economic depression since the 1930’s and the number of people one knows personally who are directly hit by it just increases.
The following post is an extract from my draft eBook Business Architecture Viewpoints, available from @LeanpubThere are some things I don’t regard as part of the Business Architecture but as part of some other domain. One reason for these exclusions is…
If we provide a service that is a monopoly or natural-monopoly, how should we relate with those who use our services? What’s the most appropriate metaphor to use, to guide our decision-making? I’ve been thinking hard about this for quite…