In my first blog post of 2014, I described how enterprise architecture delivers value in its relationship with other disciplines within the enterprise. I showed you the picture below, outlining this context of EA, and described the main focus areas of BiZZdesign’s EA service line in 2014:

1. Realizing the enterprise strategy.

2. Supporting strategic investment decisions.

3. Fostering enterprise agility.

4. Leveraging technological opportunities.

5. Controlling risk and ensuring compliance.

 

Figure 1. Enterprise Architecture in Context

In a subsequent blog post on value-driven enterprise architecture, I focused on the right-hand side of this picture, zooming on the first three of these topics, and addressed how EA provides business value by connecting the dots between strategy, capability-based planning, portfolio management, program management, and operational delivery and change processes.

Let us now have a look at the left-hand side of the figure, in particular the value of EA in managing risk, compliance and security in the enterprise (nr. 5 in the figure).

Strategic insight into risk

To be in control of the risks you run, the first thing you need is strategic insight in your organization from a risk management perspective. This requires having a consistent and up-to-date overview of your current landscape of products, processes, applications, and infrastructure, and all related risk & security aspects. Without such an overview, you are flying blind in the fog. C-level management cannot fulfill its responsibilities without knowing what the main risk-related issues are.

Having an understanding of these relationships also helps you in assessing the effects of business decisions. This provides the business with a clear insight in the enterprise risks related to, for example, introducing new products and initiatives, outsourcing business processes or IT systems, or assimilating another organization after a merger. Thus, they can weigh the risk propensity of the enterprise against the potential consequences.

Moreover, the propagation of risks throughout the enterprise is of great concern to executives and operational management. Risks in one area may entail risks in another. For example, what are the potential ripple effects of a system failure, break-in, power outage, fraud or other mishap on critical business processes, services, clients, partners, markets, …? Enterprise architecture helps you to create insight in these relations and dependencies, and thus avoid or mitigate potential disasters.

Business-driven security and risk management

A related area in which EA provides tangible business value is in aligning security and risk management with business goals and objectives. Many organizations find it difficult to decide on the right level of security measures, and business managers often see this as a technical issue that is left to the IT people. They, in turn, don’t want to take any risk and create gold-plated solutions that are quite secure but also very expensive (and often rather unfriendly towards users).

Better alignment between business goals, architectural decisions and technical implementation helps the organization to spend its security budget wisely, focused on business-relevant risks. This may even lead to both cost savings and lower risks at the same time, because you do not invest in overly strong security measures for unimportant stuff, leaving more budget to protect the things your enterprise really cares about.

Moreover, security is not something that can be ‘tacked on’ afterwards. Inherently insecure architectures and systems are very difficult to fix later on. Rather, security and risk management should be designed in from the start, using the business goals of the enterprise to decide on appropriate measures.

Regulatory compliance and auditing

Another common reason for having a mature EA practice, especially in heavily regulated sectors such as banking and insurance, is regulatory compliance. Central banks and other regulatory bodies mandate or at least strongly recommend that financial institutions have a well-established EA practice, to ensure they are in control of their operation. They may even audit these architectures or use them in other ways to assess the risks the organization runs. Of course, internal auditors, CISO’s, and risk managers benefit from using EA artifacts as well. The insights into enterprise-wide relations and dependencies that these provide are important inputs for their tasks.

Implementing standards and policies such as SEPA, Solvency II, Basel III and others requires enterprise-wide coordination, visibility and traceability from boardroom-level decisions on e.g. risk appetite of the organization, down to the implementation of measures and controls in business processes and IT systems. Enterprise architecture as a practice, and enterprise architecture models that capture these relations, are indispensable to manage the wide-ranging impact of such developments.

Next steps

To benefit fully from the use of enterprise architecture in the context of security, compliance and risk management, we suggest that you focus on the following:

• Align security and risk management with business strategy. Always view security and risk measures from the perspective of the business value they add.

• Capture and visualize risk and security aspects of your organization. Visualize hazards, risks and mitigation measures in relation to the overall architecture and business strategy.

• Measure and visualize the impact of risks and use these insights for decision making. Visualize data from e.g. penetration tests and use this to decide at the business level about necessary IT measures.

• Prioritize security projects. Calculate the business value and impact of security projects and use this to make a prioritization of IT measures.

• Use effective tool support. Software for fast and clear modeling, analyzing and visualizing provides the necessary insights. For example, BiZZdesign Architect, our easy-to-use, powerful tool for enterprise architecture and enterprise risk & security management.

In this blog post we will zoom in the Waste Scan Technique, a Lean technique that is part of the Analysis phase in the DMAIC cycle. Previous blog posts discussed different techniques of the Measure and Define Phase, and next posts will elaborate on other Analysis techniques.

What is it?
The Waste Scan focuses on waste in the process. It turns out there is a lot of waste in our processes and organizations. By recognizing and visualizing this waste we can reduce it. Lean offers many different solutions for tackling waste.

Getting started

1. The refresh button in the LeanCoach collects all yellow sticky notes; these notes are the reason for using this technique. If there are no yellow sticky notes, it can be an incentive to not use this technique.

2. The foundation of Waste Scan is the process model.

3. The process model shows waste in icons. A short introduction to waste:

   • Movement: Movement of people in the process.

   • Transport: Movement of products or information (carriers).

   • Complexity: Unnecessary complexity of the process, resources or rules.

   • Waiting: People waiting in the process.

   • Recovery work: Recovery activities in the process.

   • Inventory: Inventory or waiting lines in the process.

   • Over-processing: Adding more value than the customer is asking for.

4. Yellow sticky notes can be moved to a relevant part of the process.

5. ‘Red sticky notes’ (identified causes) can be added from scratch or from a yellow sticky note.

Tips and best practices

• Make sure that when performing this technique, you have good representation of people from the work floor.

• It is a good idea to have someone from outside of the process look over your shoulder into the process for (part of) the day, on location (observation). This helps create a good picture of the process and can open up a discussion about ingrained patterns.

 

In my previous blog post I wrote about value-driven enterprise architecture and its relations to different disciplines within the enterprise. In this blog, I want to focus on the added value of using reference architectures.

What are reference architectures?

Reference architectures are standardized architectures that provide a frame of reference for a particular domain, sector or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution architectures, i.e., they are not implemented directly. Rather, they are used as a constraint for more concrete architectures. Typically, a reference architecture includes common architecture principles, patterns, building blocks and standards.

Many domains have defined their own reference architectures. Well-known examples include:

• the BIAN service landscape for the banking industry;

• the ACORD Framework for the insurance industry;

• the eTOM business process framework for the telecommunications industry from the TMforum;

• various government reference architectures, for example the Dutch NORA and her ‘daughters’, the US FEAF or the Australian AGA;

• the defense architecture frameworks such as NAF, DODAF and MoDAF;

• reference architectures for manufacturing and supply chains such as ISA-95 and SCOR.

Most of these architectures include the common business functions/capabilities and business processes in a domain. Next to that, they may include for example common data models, communication standards and exchange formats, and sometimes even common software building blocks and other reusable assets.

eTOM framework in ArchiMate

Why use reference architectures?

So what is the value of using such reference architectures, and why and when should you employ them?

First of all, reference architectures provide a frame of reference that helps you to get an overview of a particular domain and they provide a starting point for your own enterprise architecture effort. They provide you with basic structures so you do not have to reinvent the wheel (which often turns out to be square anyway). Reference architectures are most valuable for those aspects and elements of your organization on which you do not compete with others.

For example, the business functions of a typical insurance company are largely similar to those of its competitors, as are many of its business processes. Competitive differences will most likely be in its products, pricing, customer segments, and customer relationships. Reusing industry best practices provided by reference architectures ensures that you are not behind the curve on these non-competitive aspects. We also see this in the implementation of many IT systems, where vendors such as SAP provide reference processes for large parts of an organization. Your accounting process, for example, is seldom a competitive advantage.

A second reason for using reference architectures is interoperability. In our increasingly networked world, organizations need to connect and cooperate with all manner of other parties. The standards and building blocks provided by reference architectures facilitate these connections. A related benefit is that using standards improves flexibility, because it is easier to exchange building blocks that connect via standardized interfaces; vice versa, it is much easier to develop standards if the building blocks themselves are standardized. LEGO is a perfect example, as my colleague Bas van Gils described in his blog recently.

This then brings us to a third reason for using reference architectures: mergers & acquisitions and outsourcing. If two parties speak the same language, use the same standards, and recognize the same boundaries between functions, processes and/or systems, it will be much easier to recombine their elements in new ways.

A fourth reason for using reference architectures is to facilitate benchmarking within your industry. Often, the differences between companies are not in the design of e.g. their business processes, but in their execution. Using reference designs makes it much easier to compare those execution results.

Benchmarking leads us to a fifth reason why reference architectures are important: regulatory compliance. Often, reference architectures are prescribed (or at least strongly recommended) by regulators. Accounting principles, practices and processes, for example, are evermore standardized and mandated. This leads to business reporting standards, even down to the level of exchange standards such as XBRL.

Another example is given by the Wijffels committee on the structure of Dutch banks, installed by the Ministry of Finance and the Dutch National Bank at the request of the Dutch Parliament. They have published a report which explicitly recommends banks to use industry standards such as BIAN. The context of this report is the need for decommissioning and breaking up banks in case of financial disaster (the so-called ‘living wills’). Structuring a bank along the lines of a reference architecture such as BIAN’s may certainly help in such a case. These issues are also addressed by the Dodd-Frank Act in the US and the new ECB Resolution Mechanism in the EU, so we may expect similar guidance from those sources.

How to use reference architectures?

Before you decide to use a reference architecture, some conditions should be fulfilled. First of all, a reference architecture should be community-based. Users, not vendors, should decide on best practices, and the architecture should be actively maintained by the user community. The world changes, and so should your reference architectures.

Such an active and open community process is ideally complemented by the use of open standards in describing the architectures. For example, the descriptions of the Dutch government reference architectures are largely based on the ArchiMate standard. BiZZdesign can provide many such reference architecture models out-of-the box.

The use of a reference architecture in an organization also requires governance: the organization should really commit to its use and this should be ‘enforced’ in some way. Reference architectures are only of value if people are really using them as intended and actually follow their guidance, otherwise the whole idea of reusing industry best practices breaks down.

Finally, your reference architecture of choice should provide true, actionable guidance. General architecture principles are not enough. Actual structure, for example in terms of business functions or processes, building blocks and standards, is needed to provide you with a useful backbone for your own architecture efforts.

Using reference architectures does not imply that you lose all your design freedom. Rather, you focus that freedom on those aspects of your enterprise where you make a real difference. That is where you as an architect can add the most value!

Agility is a key ability of enterprises. This is particularly true in the current tough economic times. There is a lot of (external / management) pressure to quickly respond to changing conditions: the pace at which customers demand changes, the pressure of new laws and regulations, and the ease with which competitors can copy their services leads to tremendous pressure on companies.

Data is another important theme for many organizations. Indeed, once could argue that this has been true since the rise of information technology in the 1970’s. However, if we look at the literature over the last few decades, then it seems that there has been a gradual shift away from a focus on (information) systems towards managing data as an asset in its own right. 

This is a common scenario: many organizations have grown either through an increased product portfolio with associated structures, or via a series of acquisitions and mergers and have ended up with various silos. Numerous attempts have been made to integrate these systems, either through rip-and-replace (i.e. introducing a major ERP package), introducing various interconnected interfaces, installing an Enterprise Service Bus (ESB), and so on. While these have fixed many (local) needs, the perception is that these efforts have been slow and expensive. Requests for new functionality as well as for reports have been piling up, and a business case for an enterprise data warehouse (EDW) has been in the making for a long time now: the idea of having an complete repository with all corporate data is appealing but still, building it seems like a daunting task. The following system illustrates a typical abstraction of the issue:

The diagram shows that there are many (logical) data flows between various systems which somehow seem to converge at the (planned) BI system. Some of these flows pass through the Master Data Management (MDM) hub where some integration and standardization takes place. Moving data across the landscape through each of these flows takes time and is a potential source of errors. Indeed, there have been some perceived data quality (DQ) issues: there are minor differences between definitions in various systems, derivation rules and key calculations (e.g. handling tax rates and discount schemes) differ and are hard coded, text fields are misused, etcetera.  On top of that all, there is also a wide-spread idea that semi- and unstructured value such as E-mail and documents in the repository potentially have a lot of value. 

This is a situation where data virtualization techniques can help. In the following posting we will show how that works.

For many organizations the enterprise landscape is growing out of control. Simply keeping up with competition and evolving markets means that organizations constantly renew services offered to customers. These new services are supported by new processes, applications and infrastructure that are added to the landscape, making it larger and more complex. Other organizations are confronted with mergers, leading to information systems that have duplicate functionality. They lack an overview of the ever-growing application landscape and, therefore, have no proper basis for making well-informed decisions. 

Enterprise portfolio management

To gain control over these large landscapes, it is necessary to move away from the occasional rationalization effort and the ad hoc manner of managing these landscapes. Therefore, organizations look for a way to implement a continuous process for evaluating the landscape against business-relevant criteria, deciding on investment priorities based on this evaluation, and acting upon these decisions. Many organizations choose to gather, for example, applications and projects into portfolios. Portfolio managers gain a better overview of the landscape and can manage it as a group, instead of having to manage each application and project by itself. Budget can be allocated at the more strategic portfolio level, avoiding detailed discussions by upper-level management on many small initiatives. 

Enterprise Portfolio Management (EPM) is an integrated portfolio management approach that tightly manages strategic planning against the various portfolios of interdependent assets, like product portfolios and project portfolios.  In this blog series we illustrate what EPM can do for your organization. We show how EPM creates an enterprise-wide view of your organization that takes all of its levels, from strategy to infrastructure, into account. In this way, investment decisions contribute to the strategy of the enterprise. 

There is a difference between managing the things you have (assets) and the things you want (changes). An asset portfolio can consist, for example, of services, products, applications or servers. Managing such a portfolio means that you consider which assets you want to acquire, keep, change, replace or phase out. Based on these decisions, change initiatives are formulated to realize the changes. These initiatives can take the form of the familiar programs and projects, but increasingly we see organizations moving towards a way of working based on value streams and continuous delivery. Our EPM approach applies to these as well. 

These initiatives, in turn, are managed in portfolios where decisions on resource allocation, investments and planning are made. Detailed roadmaps show, for example, which product can be launched at what moment. Periodically, both the asset and change portfolios are assessed and readjusted based on their performance and changing business priorities.

The relation with Enterprise Architecture

Enterprise architecture provides an abundance of information on your organization. Using this as a basis for portfolio management will bring an enterprise wide-view of the landscape, while connecting it to different disciplines such as strategic management. 

Defining meaningful portfolios is a prerequisite for successful portfolio management. Decisions on, for example, which products, projects or applications are managed in one portfolio define the success or failure of EPM for your organization. The enterprise architecture assists in this discussion by providing the interdependencies between the different elements of a portfolio and their context. For example, an application portfolio might hold applications related to a certain channel (e.g. the Internet domain), a specific business process or function (e.g. Sales), a specific stakeholder group, a technology stack, or any other coherent grouping deemed relevant from a business perspective. 

Another important reason to use the enterprise architecture is the enterprise-wide view it provides. Especially relating portfolios to the organizational strategy is a goal many CxOs have. Aligning the different disciplines ensures coherent and effective management on a strategic, business and technical level. 

You can use your enterprise architecture to compare different views of the organization, for example to conduct an impact analysis or do a cost calculation for different investment alternatives, since these views are based on the same underlying model. To illustrate this, consider the following example: A software vendor offers a monitoring application to its customers. Its basic functionality is monitoring the performance of other applications such as websites. It is, however, possible to purchase additional functionality that allows programming robots for performing composite monitoring. This enables monitoring whether, for example, logon functionality of a website is working properly. The application portfolio manager sees this as one application, which should be managed as a whole. However, the project portfolio manager considers the implementation of this as two distinct projects. For application and project portfolio managers to integrate their management decisions, they need to have a consistent view on the application landscape. Using the enterprise architecture as an agreed-upon underlying model, ensures consistent and, therefore comparable, views across disciplines. 

Towards successful EPM

So far, we discussed which ingredients are needed to make portfolio management a success, but  accomplishing this is no sinecure. It is highly important to conduct a thorough design phase, in which stakeholders and their goals and concerns are identified, portfolios are defined that are aligned with these goals, and a valuation model is designed that addresses the concerns of these stakeholders. In other words, it is important to think about what you want to manage and for whom you are doing this. 

The stakeholder concerns are then addressed in dashboards that visualize portfolio scores of the applicable metrics in an intuitive manner. Dashboards are a powerful way of addressing such concerns in a direct way. An effective dashboard shows the relevant information in a clear, intuitive and understandable manner.

After designing your EPM approach, you can operationalize your plans and inventory the assets and change initiatives, analyze the value they have and make (investment) decisions using the designed dashboards.

Outlook

This series of blogs is structured as follows:

• We start the series with an in-depth discussion of the way in which organizations can use their Enterprise Architecture as a solid basis for Enterprise Portfolio Management.
• In the next blog, we discuss how you can implement a successful EPM approach in your organization. We demonstrate how concerns of stakeholders can be addressed effectively through well designed dashboards by following the EPM cycle. 
• We conclude this series by showing how EPM is used in practice through an elaborate case study. 

The next blog will discuss how to use your EA for portfolio management. In the meantime , if you are interested in reading a more in-depth discussion, please, download our whitepaper on Application Portfolio Management. For any questions, please, send an email to: l.bodenstaff@bizzdesign.com

Agility is a key ability of enterprises. This is particularly true in the current tough economic times. There is a lot of (external / management) pressure to quickly respond to changing conditions: the pace at which customers demand changes, the pressure of new laws and regulations, and the ease with which competitors can copy their services leads to tremendous pressure on companies.

Data is another important theme for many organizations. Indeed, once could argue that this has been true since the rise of information technology in the 1970’s. However, if we look at the literature over the last few decades, then it seems that there has been a gradual shift away from a focus on (information) systems towards managing data as an asset in its own right. 

This is a common scenario: many organizations have grown either through an increased product portfolio with associated structures, or via a series of acquisitions and mergers and have ended up with various silos. Numerous attempts have been made to integrate these systems, either through rip-and-replace (i.e. introducing a major ERP package), introducing various interconnected interfaces, installing an Enterprise Service Bus (ESB), and so on. While these have fixed many (local) needs, the perception is that these efforts have been slow and expensive. Requests for new functionality as well as for reports have been piling up, and a business case for an enterprise data warehouse (EDW) has been in the making for a long time now: the idea of having an complete repository with all corporate data is appealing but still, building it seems like a daunting task. The following system illustrates a typical abstraction of the issue:

The diagram shows that there are many (logical) data flows between various systems which somehow seem to converge at the (planned) BI system. Some of these flows pass through the Master Data Management (MDM) hub where some integration and standardization takes place. Moving data across the landscape through each of these flows takes time and is a potential source of errors. Indeed, there have been some perceived data quality (DQ) issues: there are minor differences between definitions in various systems, derivation rules and key calculations (e.g. handling tax rates and discount schemes) differ and are hard coded, text fields are misused, etcetera.  On top of that all, there is also a wide-spread idea that semi- and unstructured value such as E-mail and documents in the repository potentially have a lot of value. 

This is a situation where data virtualization techniques can help. In the following posting we will show how that works.

The Museu Nacional d’art de Catalunya is one of the most impressive museums in all of Barcelona. Not only because of its impressive collection of late medieval art, also because of the majestic location: the Palau Nacional is an Italian styled palace with large staircases, fountains etcetera. Unfortunately, part of the balustrade of one of the staircases has crumbled and fallen apart. Guess what was used to fix it…

As many of us have experienced when we were younger, pretty much anything can be made out of LEGO™ bricks. Generation after generation has been inspired to build impressive buildings, vehicles, landscapes and so on.

 

 

 

 

Using LEGO

Part of the appeal, no doubt, is the fact that these LEGO bricks have become so universal and maximize creative re-use: everything fits with everything else, and the only limit on what can be built is your own imagination. As the following examples show, some people take this to the extreme:

• A miniature of the Beijing Olympics stadium
  
   
• The infamous Millennium Falcon from Star Wars
  
   
• An actual telephone pole in Brazil
  

There are many ways to go about being creative with LEGO’s. Some of us rely on the instruction manual and build things exactly as designed. For budding architects, however, the fun is in thinking outside the box.

LEGO and Enterprise Architecture

Many enterprise architects face similar challenges, albeit on a different scale. Here the trick is not to combine brightly colored LEGO’s, but to figure out an effective combination of processes, data, and systems to achieve the goals of the enterprise. Aspects such as “standardization” and “integration” also play an important role in this case as described by (Ross et al., 2006):

Process standardization has the advantage of efficiency: doing the same things in similar ways across the enterprise. Similarly, process integration – typically through data – has the advantage of using a single view of the world which can be used to build a unique offering for customers. Of course, some people want both…

The operating model gives enterprise architects the option to set a course for the enterprise in terms of (requirements for) integration and standardization in the context of the goals of the enterprise.

Some food for thought: with LEGO’s there seems to be a natural progression to go from “build as specified” to “experiment”. What does that mean for enterprise architects? Can we expect more (agile) architectures, loosely based on some form of blueprint in ArchiMate?
And what does that tell us about the future of our enterprises?

Challenges for the LEGO company

Recently, a lot has been written about the (change in) strategy for LEGO (e.g. here and here). Where the success of LEGO initially came from standardization of bricks and the way they interconnect, it seems that an interesting change of direction was required: differentiation. By offering customers more choice (e.g. the movie-related theme, the ninjago theme) as well as leverage the digital revolution (with e.g. iPad apps), the brand managed to spark the imagination of a large customer base. 

The question, of course, is: what’s next? Here are two tips / things to consider:

1. Get the attention of the business market: a lot of organizations have discovered that ‘serious gaming’ is ‘serious business’. We see a lot of organizations experiment with simulation sessions which could be an ideal audience.
2. Impressionist LEGO: rather than delivering a complete and detailed LEGO-blueprint, give each customer a kit with bricks as well as a diagram in “impressionist style”. Perhaps this can be combined with a competition: who builds the coolest structure, given the content of the box?

If you have questions, or other thoughts about the use of LEGO: drop me a note at b.vangils@bizzdesign.com , or leave a comment below. Thanks!

In my previous blog post on Enterprise Architecture at BiZZdesign in 2014, I described how the true value of architecture lies in its relationship with other disciplines within the enterprise.

We identified five major areas where EA touches these other disciplines: 

1. Realizing the enterprise strategy. 
2. Supporting strategic investment decisions. 
3. Fostering enterprise agility. 
4. Leveraging technological opportunities.  
5. Controlling risk and ensuring compliance. 

​What I did not address in that blog post, was the coherence between these areas. Let us now zoom in on the first three of these and see how they are related.

Capability-based planning

An important instrument in realizing enterprise strategy is capability-based planning. Business capabilities are a pivot between strategy and realization. On the one hand they provide a high-level view of the current and desired abilities of an organization, in relation to the organization’s strategy and its environment. On the other hand, they comprise various elements (people, processes, systems, and so on) that can be described, designed and realized using enterprise architecture approaches.

Enterprise portfolio management

The central position of business capabilities and their recognizable level of granularity makes business capabilities an ideal focal point for investment decisions. Based on your enterprise strategy, you decide which capabilities need to be developed. You can consider the set of capabilities of your enterprise as a portfolio, and allocate your budgets based on the business value of these capabilities. In our whitepaper on portfolio management, you can find some of our ideas on managing various asset portfolios. These techniques apply equally well to managing a portfolio of capabilities.

Capability-based planning helps you in developing and improve the necessary resources of your organization. Enterprise architecture offers an integral approach for realizing these developments and improvements as a coherent whole. Modeling capabilities in relation to the rest of your EA, of course using the ArchiMate modeling language, is one of our current R&D topics. More on capabilities, capability mapping, capability modeling and capability-based planning will follow in future blog posts.

From project to value stream

Modern approaches to realization are doing away with the classical project and waterfall ways of thinking. (As an aside: thinking in projects is a major cause for the disappointing performance of many IT organizations; more on this will follow in another blog post). Those modern methods use a life-cycle and value-stream perspective. The assets that make up your enterprise are managed across their entire life cycle, doing away with the artificial distinction between ‘development’ and ‘maintenance’. 

Furthermore, the realization activities are organized as value streams, using the flow-based way of thinking from approaches such as Lean. Continuous delivery by agile & DevOps teams provides a steady stream of business value, in close interaction with the customer and other stakeholders.

Focus on business value and outcomes

Aligning these value streams with the business capabilities mentioned before, gives you a clear, business-driven focus for allocating your investment budgets. Capability-based portfolio management lets you prioritize these investments in a well-founded way. 

Iteratively assessing, refining and realigning this portfolio every few months helps you to keep doing  the right things. Instead of finishing the last drop of project budget in gold-plating a result, you can decide to re-allocate budget to initiatives that create more added value. Such a value-driven, integrated and cyclic approach delivers business outcomes in rapid iterations. This increases the speed with which your organization can respond to its environment and hence improves its business agility.

Towards value-driven enterprise architecture

A value-driven approach to enterprise architecture plays a central role in all this. It supports portfolio management with the analyses needed to determine the expected value, cost and risk of various initiatives. It provides the necessary input for prioritizing and planning changes to your business and IT landscape. It gives you program-level coordination across value streams to realize these changes in a coherent manner, and it fosters reuse of valuable knowledge and assets. Finally, it allows you to track the realization of the expected benefits across the business and IT landscape, and hence to correct your course if necessary. 

Next to this value orientation, the flow-based mindset outlined above should also be adopted by architects. By delivering a steady stream of analyses and changes in a ‘think big, act small’ way, they can help the organization realize a long-term vision one step at a time. 

All of this gives us a more detailed picture of the right-hand side of the previous figure, as shown below. Here, you see how enterprise architecture helps you ‘connect the dots’ between strategy and operation. In this way, enterprise architecture truly becomes the bridge between the strategic direction of the organization and its day-to-day operations and change processes.

First steps

A first step you can take is to create a high-level overview of the important business capabilities of your organization. Such a capability map is very helpful in finding out what is really important and where the added value of your enterprise can be found. By googling ‘business capability map’, you will find many examples to inspire you. 

Secondly, you might have a critical look at your current investment decision making. What are the information needs of the decision makers, and are they catered for? If not, what could you do with the information you already possess, for example in your architecture models, to help them? Providing such management information is a great way to increase your visibility and added value as an architect.

Outlook

In future blog posts, we will discuss many of the topics mentioned above. We will go into business capabilities, capability maps, and capability-based planning, and the use of ArchiMate to model these. Portfolio management and its relations to capability-based planning and enterprise architecture is another topic we will address. 

Furthermore, we will describe the use of architecture and the changing role of the architect in the context of agile development methods. Of course, your EA practice itself should also focus on the value it adds. In another blog series, we are currently addressing the use of Lean practices in EA. Stay tuned for more on this.

Finally, enterprise architecture can contribute to the agility of your information systems landscape itself. More on that will also follow in this blog series.

This Blog focusses on the Analysis selection, the last step of the Measure phase (M in DMAIC). This step creates a bridge between the Measure and the Analysis Phase. 

What is it?

The Analysis selection closes the Measure phase. The Measure techniques have helped us collect information, facts and ideas. This has resulted in many (potential) issues in the process (yellow sticky notes). In the Analysis selection we choose the techniques that we want to use to take a closer look at the issue at hand.

Getting started

1. The refresh button in the LeanCoach collects all flagged yellow sticky notes.
2. On every yellow sticky note you can indicate which technique you want to use for further research. You can do this by clicking on the little shopping cart, or by clicking on the icon at the top of the screen. Every yellow sticky note allows you to select multiple techniques, which are:
   1. ​​​​​Proces Waste Scan: analysis of standard forms of waste in the process. 
   2. Value Stream Map: analysis of (customer) value in the process. Which activities add value? 
   3. Voice of the Customer: which part of the process involves the customer? 
   4. Bottleneck Scan: where in the process do we find ‘bottlenecks’?
   5. Hidden factory: which activities in the process are repeated because the process didn’t work the first time? This can be recovery work and handling complaints.
   6. Context Analysis: which problems occur in the context of the process? Unnecessary rules, poor ICT support and insufficient motivated personnel.
3. ​​​By selecting a technique on a yellow sticky note, this sticky note becomes visible in performing this technique.

​Tips and best practices

• Try to select at least one technique for every yellow sticky note. If the issue is not related to the process, you are better off choosing the Context Analysis technique.

​If it is unclear what the objective is of different techniques, it is advisable to read upcoming Blogs about these techniques or the tutorials in the LeanCoach.

Last technique in the Measure phase (M in DMAIC), the Fact collection will be the subject of this Blogpost. Facts and numbers about potential causes of problems and the process in general will give you a better understanding of the process and the way…

The life of a process consultant results in experiencing some ordinary shopping-situations through a different lens. In this blog I share my personal experience when buying a Pax wardrobe at IKEA and how I think the process in the self-serve warehouse…

On March 20, we organized a workshop at BiZZdesign for enterprise architects in healthcare. A mixed group, from hospitals and other healthcare providers. In the workshop, various issues were discussed. We want to highlight some of these topics in this…