|Read more about this book|
(For more resources on this subject, see here.)
Recently, I had a meeting with the directors of a major household brand. They had just finished completing a strategic review of the business, which had been signed off by the board. They had numerous stakeholders to satisfy, and naturally the final result was a compromise, which was reached after months of meetings. I was with an experienced business coach who asked the CEO, "So, how will you know if you have succeeded?". The CEO had difficulty in answering the question. One of his senior managers in the room jumped to his rescue: "Oh, we are working out what we want to measure. We have agreed on some of the measures, but haven't yet put any numbers against them."
The coach asked: "How do people in the organization feel about the new strategy?"
The manager replied saying, "It's a good question. There are a lot of people who feel that it was a waste of time and they just want to get back to the real work. We have a team of very passionate and committed people, but they see strategy as navel gazing."
We realized that the strategy was doomed. It seems logical to define the goals and then identify the measures. In practice, it is often easier to do it the other way round, even though that is counter-intuitive. First, define the measures of success and then articulate these measures as goals. The employees were right to be dubious.
There are various ways to create, read, update, and delete information. These solutions fall into two major approaches—drawing and modeling. Drawing is still the approach adopted by many organizations because it is cheaper. Most companies that have considered using ProVision® have Microsoft Visio installed on every user desktop. As far as a project manager is concerned, Visio is a free resource. The project manager doesn't need to ask for funds, and if they do, then the manager will ask why they aren't using Visio. This article explains the limitations of drawing and why modeling is best practice and essential to support a sustainable strategy. The reader can use this information to make their business case compelling and get the funds that they need to do the job properly. Areas covered also include:
- The benefits of moving to a central repository. (What needs to be stored and how users can access it.)
- Are we building architecture or doing design? (The importance of language in getting your message across.)
- Better decisions now. (The purpose and notion of good enough architecture.)
- ProVision® and Metastorm BPM. (Is this Metastorm's unique selling point?)
The benefits of moving to a central repository
It is important to understand the difference between a drawing tool and a visual relational database such as ProVision®. The outputs can look identical. Because drawing tools are so much cheaper, why would you invest in ProVision®?
There are a number of drawing packages available, Microsoft Visio is the key player in this market. It is a drawing package that is optimized for business diagrams. Modelers can select pre-built stencils to create models rapidly. As Visio is often installed already, it is the tool of choice of many business analysts.
Designed to scale
If all you need to do is visually represent an aspect of a business, then there is nothing wrong with Visio. However, its limitations soon become apparent. To understand the key differences, I need to explain some basic concepts about ProVision®. These concepts are the reason why you can manage hundreds of models in ProVision®. It has been designed to scale. The core concepts are:
ProVision® uses objects to represent business concepts. Everything you see—a role, system, process, or a goal is an object. Every object has a name and an icon. After that, it is up to you how much more detail you want to add. All objects can have associations with other objects. These associations will vary, according to the type of object.
A link is a special type of object. It is displayed as a line that connects two objects. You can modify the way the line displays, that is, change its color, thickness, or arrow shape. Links appear in their own area in the object inventory. Some types of link can have a payload (a deliverable) and events associated with them. For example, the link between two activities is called a workflow link. This link can display the deliverable that is passed as an output from one activity to the other. It can also display the event that triggers the deliverable. Both deliverables and events are optional. In many cases, it is obvious what the deliverable or event would be. To distinguish between an event and a deliverable, ProVision® places the name of the event inside double quotation marks.
In the example shown in the following figure, once the event named "Model ready to review" is triggered, the deliverable called Draft Model becomes the input for the Review Model activity:
A model is a special kind of object that contains other objects. Every model must have an object that is designated as the subject of the model. ProVision® provides three types of model—hierarchical, non-hierarchical, and navigator. Hierarchical models typically allow only one object type to appear. For example, a Systems model can be used to create only the hierarchical relationships of systems. No other object type can be added. Even if you create a custom object, you will not be permitted to add it to a hierarchical model.
Non-hierarchical models permit more than one object type to appear, so that you can show predefined relationships other than parent-child relationships between these objects. For example, a Systems Interaction model will allow you to demonstrate relationships between systems and hardware.
The Navigator model is a special model that you can use when you are unable to express the relationships that you want using one of the other model types. You can use virtually any object type on a Navigator model. This is both its strength and weakness. As any object can be used, you can become overwhelmed by the choices. The Navigator model is the only model type that allows you to display models as well as objects. By default, these display as thumbnails of the full model. In the following example, a Navigator model shows a thumbnail of the Approval Process workflow model. The subject of the workflow model is the activity called Approval Process. It has been placed to the right to demonstrate the difference.
The Navigator model has one more purpose. You can use it to visually express indirect relationships. For example, a goal may be realized by delivering a product or service to a customer group. The product requires processes. Each process decomposes down into a series of activities, some of which might require certain computer systems to be in a running state. There is no direct relationship between the goal and the computer system. There is an indirect relationship, which you can visualize using a Navigator model.
Notebook and file
Objects, links, and models are stored in Notebooks. If you think of a Notebook as a physical book, then the models are equivalent to chapters. Each model tells a story. Inside each story, there are words. Objects are equivalent to words. Links create phrases.
Several Notebooks can be stored together. They share a common modeling language that changes the look and feel of objects, links, and models. Other than that, each Notebook is independent. So, it is possible to have two objects in different notebooks that have the same name and type but are completely different. Objects and models can be dragged from one Notebook to another. You can save a Notebook under a different name and thus use the first Notebook as a template for the second.
A File is the logical equivalent of a Notebook. The main difference is that a File can be saved anywhere on a computer and then e-mailed or copied onto a memory stick for transfer. So, Files are used to share and exchange Notebooks with other users.
Only one Repository can be open at any one time. Only one Notebook can be open within the Repository. In the example shown in the next diagram, the Sample Repository appears in bold writing to highlight that it is open. Also, the PackT Notebook has a different icon to distinguish that it is the Notebook being viewed.
All Notebooks are stored in Repositories. A Repository can contain many Notebooks (in practice most users would be unlikely to have more than 50, and typically around 10). The modeling language is associated with a Repository, and once it is made the default language, it changes the names, look and feel of all objects, links, and models, irrespective of which Notebook they are in. In the following example, the Sample Repository is bold to indicate that it is open. The POC Repository has a world icon to represent that it is stored on a remote server and accessed via Knowledge Exchange®. By contrast, local Repositories have a pyramid icon.
Now that you have understood these basic concepts, let's see how ProVision® varies from a drawing package such as Visio.
|Read more about this book|
(For more resources on this subject, see here.)
Store once, reuse many times
Imagine that you build a model, which is an organization chart. On the chart is an object used to represent the Accounts Department.
Now you build a separate model, which is a workflow. One of the swim lanes is the Accounts Department.
After a restructure, the Accounts Department is now called the Finance Department. You will now need to find every instance of the old Accounts Department object and rename it as Finance Department. In this simple example, there are only two models. Assume that there are 50 models! How would you keep track of them all?
To try and get round this maintenance issue, Visio modelers create huge diagrams so that everything is on the one page. System diagrams are a common example. The maintenance issue is solved, but now the drawing is so detailed and complex that only the modeler actually understands it. Cramming everything into one Visio model also makes it a major time-consuming challenge to modify the model after receiving user input. So, while Visio appears cheaper, the cost has just shifted to pay an extra salary.
The main purpose of modeling is to visually explain something, which might otherwise require several pages of text. Successful modeling simplifies and tells a story. I recommend that no model should have more than 15 objects on it. The more objects, the more complex it becomes. If the viewer doesn't understand the story, then the model is of little value as a communication tool.
When you draw a model using ProVision®, the object is stored in the object inventory. Any changes to one instance automatically update all other instances of the same object. There is no need to create and edit objects in the object inventory. The act of adding, updating, or deleting an object that is displayed on the current model automatically corrects the object inventory. This means that there is no chance of accidentally forgetting to update a specific model.
When you examine the object inventory, you can see all the places in which an object is used. Naturally, you can also rename or delete objects directly from within the object inventory. In the following example, we can see that the activity object called Approve Model is used only in the Approval Process workflow model:
ProVision® enables the user to nest models. This is why you can create models that are simple to understand, in part because they do not contain more than 15 objects. Each object can become the subject of a child or nested model. If you need to see the detail, you can just click into the nested model. Like Russian dolls, each model can contain another model inside it.
As this is not possible in Visio, modelers have to change their mindset. The modelers are used to cramming everything onto the one model, so it takes time to understand that this is neither necessary nor desirable.
A drawing is not a model but is a static image. The objects that a drawing contains are drawn directly onto the blank sheet and that is where they remain. When you use ProVision®, you are using the model as a means to update the object inventory. Everything is stored centrally.
Knowledge of a business is scattered. Everyone knows a lot about the area for which they are responsible and less about the rest of the business. Creating a central repository requires communication and collaboration. So, what happens when two people need to make changes to the object inventory? In the previous example, the name of the Accounts Department had to be updated to become the Finance Department.
One person might be responsible for maintaining and updating the organizational chart. Another person keeps the workflow models up to date. The same object called Accounts Department appears in both models. How can one person make the changes without creating problems for the other?
ProVision® follows the same process that has been used by software developers for many years. Models and objects are stored in a central location and checked out when required. ProVision® locks the objects. The next person who wants to use those objects will find that they are now read-only. They will have to wait until the first person releases the objects by checking them back in.
It is quite common for several modelers to be working on the same information at the same time. Without this ability to lock and unlock objects, it would be easy for one person to accidentally overwrite the work of another. Needless to say, Visio does not have this capability.
In the latest version of the companion product, Knowledge Exchange®, the ability to share objects is taken to the next level. It is now possible to store objects in a central remote repository and then hyperlink to them. In this way, a master list of objects can be reused by many modelers working in multiple Notebooks. If the master object changes, this will be reflected across all the Notebooks.
Architecture or design
Enterprise Architecture is a response to increasing rates of change and complexity. Once a business reaches a certain size, it becomes increasingly difficult to remain responsive to the changing business environment. As a consequence, the systems and processes do not support the business objectives. This lack of alignment reduces the return on investment.
In order to write your business case, you need to have a high-level understanding of what Enterprise Architecture is.
When the founder of Enterprise Architecture, John Zachman, started to think about how to make models of a business, he looked at how engineers created and maintained models of large complex structures such as skyscrapers and jumbo jets. These constructs had to be managed and maintained over many years. They comprised hundreds of thousands of parts manufactured by different companies. As time passed, the technology used to create parts would change. Different groups wanted to see the information and hence filters were required. Zachman wondered, "How do they manage all of this?"
He thought that if it was possible to design systems to manufacture goods and services, would it not be possible to design the actual businesses themselves? In the late nineteenth century, there were numerous screw manufacturers. There was no standard of what a screw looked like. If you needed a replacement, you had to go back to the original company. While this was good for the company, it was bad for the growth of the industry. Fast forward 100 years and the idea of standard reusable parts is well established in manufacturing, and yet it is still hard to acquire, off the shelf, standard reusable business processes.
Much of what an organization does is the same as every other. Virtually all organizations hire staff, pay bills, and rent premises. Within each industry group, there are great similarities. Running one university is not so different from running another. All health clubs do similar things. What if an organization could just pick best practice business processes? This would mean they could focus on their competitive differences.
Zachman's work, first published in 1987, has had a profound influence. Many other frameworks have been developed over the past two decades, which are modifications or refinements.
He applied the lessons that he learned and created an architectural framework. It has evolved over time. Information is classified by the six questions that we can ask about any area of enquiry: what, how, where, who, when, and why? The answers are stored at five levels, representing the different perspectives of context, concept, logical, physical, and detailed views. These levels align with different roles:
- The planner manages the context
- The owner manages the concept
- The designer manages the logical layer
- The builder manages the physical layer
- The sub-contractor provides the individual components
Sometimes the framework shows a sixth row, which represents how the organization appears to the world.
The framework adheres to a set of rules. While the rows follow a logical sequence, the columns can be displayed in any order. The structure creates cells, each of which can store information only of a certain type at any level of detail. Thus, we say that each cell is normalized, with each column and each row having a specific and unique set of characteristics. The information in all of the cells is a complete expression of a business entity. You cannot add rows or columns. Zachman does not tell the modeler much about methodology:
- What is the sequence in which the framework should be built?
- What level of detail is adequate?
- Are there cells which are more important than others?
- Are some rows or columns more important than others?
- What process should we follow?
Zachman leaves it up to others to answer these questions.
|Read more about this book|
(For more resources on this subject, see here.)
The Open Group Architecture Framework (TOGAF) is the best-known process. While it is called a framework, it actually also describes the process by which information is gathered, maintained, and used to make decisions. This process is called the Architecture Development Method (ADM). After defining the framework and principles, the ADM is a continuous loop, consisting of eight phases and a Requirements Management process:
- Architecture Vision
- Business Architecture
- Information Systems Architectures
- Technology Architecture
- Opportunities and Solutions
- Migration Planning
- Implementation Governance
- Architecture Change Management
Consequently, many modelers combine Zachman, which gives them a consistent taxonomy, and TOGAF, which gives them a sequence in which to record the information. However, if you look at the language and origins of TOGAF, you can easily make out that it is a methodology for changing technology and systems. It is only in TOGAF 9 that we begin to see business architecture content. The TOGAF 9 user guide is 778 pages long, which in itself makes it difficult to execute. The original promise of Enterprise Architecture was that it would be a simple way to describe the whole enterprise, not just focus on the systems that support it. To be fair to the Open Group, they have invested significantly in ArchiMate—a lightweight agile framework that is business-focused.
Federal Enterprise Architecture
Since 2006, the Federal Enterprise Architecture (FEA) has attempted to create an integrated framework and methodology for one of the largest and most complex organizations on the planet—the US government.
The FEA divides business into core mission-area segments and business-services segments. Core segments reflect what the organization exists for. Business segments describe the functions, such as HR and Financial Management, that support the core mission for a specific agency. Enterprise services are functions that cross agency boundaries. For example, Records Management and Security is designated to be enterprise-wide.
The FEA includes five reference models that are designed to provide a common language across agencies. The purpose, of course, is to facilitate cooperation between Agencies. By creating a shared understanding, the FEA hopes to reduce waste and duplication.
The FEA has a four step process for preparing projects.
- Analyze and demonstrate how the project aligns with the overall organizational plan.
- Describe the future architectural state, the measures for success, options considered, and the proposed approach.
- Look at project funding.
- Produce a project plan with all the normal features.
Success is measured by how complete the architecture is, how extensively it is used to inform decisions, and how successful the programs are. The FEA color codes success using a traffic lights system (green, yellow, and red).
Refer to A Comparison of the Top Four Enterprise-Architecture Methodologies by Roger Sessions of ObjectWatch, Inc. for an excellent discussion on this topic: http://msdn.microsoft. com/en-us/library/bb466232.aspx.
Open Text Metastorm's unique strengths
Business Process Analysis (BPA), Enterprise Architecture (EA), and Business Process Management (BPM) are three separate but related disciplines. Open Text Metastorm Enterprise was the first vendor to bring all three together in one suite of applications and is a leader in all three areas. Business Process Analysis is sometimes called Business Process Mapping, but as this creates the same acronym as Business Process Management, I prefer not to use it. The purpose of BPA is to describe a process. A map, or a model, is one way to do this.
ProVision® is an Enterprise Architecture and BPA tool. There are two versions of the toolset. ProVision® for BPA is just a cut down version of ProVision®. Thus business analysts and enterprise architects can work on the same data.
Open Text Metastorm BPM
Open Text Metastorm BPM enables a business to describe and monitor instances of a process in real time. Each time a process is triggered, Open Text Metastorm BPM tracks its progress from start to finish. The statistical information gathered, such as how long each step takes, is then used to understand how well a process is running. The data can be brought into ProVision® and used to simulate alternative scenarios. For example, imagine that you are a law firm. One of the processes is Client Onboarding—the process by which the firm does due diligence on the client. Has the firm acted against them in the past? Is the firm already representing a client where there might be a conflict of interest? With hundreds, sometimes thousands of clients, checking the files and talking to partners is going to take some work. The firm can't afford to make a mistake, which at best might be embarrassing. Like many processes, part of this work is manual. This means it can get stuck if people are away, don't respond to requests, or are just too busy. It is very easy to overlook or forget something.
After implementing Open Text Metastorm BPM, every time a new client comes onboard, the application opens a new folder containing everything known about that specific instance. As each step of the process is completed, Open Text Metastorm BPM keeps an audit trail with dates, times, and the name of the person completing the step. If a folder gets stuck, it can be re-routed to someone less busy. Open Text Metastorm BPM integrates with other systems such as CRM, e-mail, and SMS. Managers can receive alerts before a delay becomes a drama, allowing them to intervene rather than react. They can be provided with consoles where they can monitor all the processes for which they are responsible.
As participants complete their tasks, they can tell Open Text Metastorm BPM by updating the folder. For example, the folder might be accessed via a website.
In many cases, users are unaware that they are using Open Text Metastorm BPM. A business manager might need to give an approval. Users might receive an e-mail asking them to select a yes or no button, and, depending on their response, the folder is routed in different ways. Open Text Metastorm BPM integrates with current editions of Office so that participants can run processes from within familiar applications such as MS Word.
Open Text Metastorm BPM competes with a number of other applications. Its strength is that it is very fast to implement, taking weeks where others might take over a year. It is aimed at processes that have a lot of manual steps.
Because Open Text Metastorm BPM sits above all steps, whether manual or automated, it is possible to switch out systems and processes underneath, without much work. So, for example, if you decide to change CRM vendors, Open Text Metastorm BPM can adjust without much effort.
Although a process model is efficient, and reflects accurately the best way to do the work, the world continues to change. While you can encourage or mandate participants, the probability is that the process model and reality will quickly diverge. The beauty of Open Text Metastorm BPM is that it ensures that the process is followed the way that it is intended, and, if a better way is discovered, the Open Text Metastorm BPM model is easy to adjust.
The competitive advantage
Competing modeling products to ProVision® also have simulation engines. However, without easy access to the live data, business analysts make guesses about how a process runs in practice. These guesses can be improved by surveys and conversations with suppliers and customers, which is both time and money consuming. One ProVision® competitive advantage is the integration of the modeling tool and the execution engine. Organizations that adopt ProVision® Enterprise can transfer process data between the modeling and execution applications, and back again. However, few organizations buy based on this point as it is regarded as too esoteric. From a customer's perspective, the purchase decision is usually made on ease of use, scalability, access to local expertise, and breadth of use.
Many organizations start by using ProVision® and, as they mature, acquire Open Text Metastorm BPM. Because of the cost of Open Text Metastorm BPM, it is usually applied to processes that are high volume, high value, or both.
Better decisions now
Why better? In a world where change and complexity are increasing, it is not possible to know if a choice is the best possible one. Many organizations do not model their businesses. They rely on the experience and intelligence of their decision makers. Good decisions can be made without the use of models. Therefore, we can only argue that the decisions that are informed by modeling are better, not ideal or perfect.
I base this argument on the following points:
- All the key information needed to make a decision is stored centrally and thus available for review.
- The information can be displayed in multiple ways—visually, as text, as graphs and tables, to suit the intended audience.
- The information can be filtered to show the appropriate level of detail.
- The information typically comes from multiple sources and thus represents a collective view.
- To combine the different data sources, the information depends on a consistent framework and methodology.
- The information has been subjected to quality checks and is thus more likely to be complete, current, and accurate.
- The quality checks help demonstrate if there are gaps, thus reducing the chance of decisions being made based on false assumptions.
Without a central repository, each decision maker constructs mental models. These can change in an instant. They are stored inside our heads and are invisible. It is very difficult to know how complete, current, or consistent they are. If the person leaves the organization, or is temporarily unavailable, access to the information is very difficult. It might be ignored. Re-building the information is expensive and can take time.
Why decisions? When building a model of an organization, it is very easy to get lost in the detail. Adding detail to the model takes more time and increases the task of maintaining the model exponentially. The acid test is, will this additional detail help the organization make better decisions? There is an important distinction between information and decisions. More information does not correlate to better decisions. You need just enough information to make a better decision than you would if you had not had a central model.
Why now? Business leaders have to make decisions today. The world is changing rapidly and they have to make the best possible decision with the available facts.
The business case for implementing ProVision® is that it will enable the business to make better decisions now. As long as the team sticks to this mantra, they will succeed.
In this article we saw some general principles of modeling and the key benefits of using the ProVision® modeling solution, specifically to support business strategy.
- Visual Studio 2010 Test Types[article]
- An Overview of Microsoft Sure Step [article]
- Upgrading with Microsoft Sure Step [article]
- Microsoft Enterprise Library: Security Application Block [article]
- Microsoft Sharepoint 2010: Rules for End User Deployment [article]
- Tips and Tricks for Process Modeling in Open Text Metastorm[article]