BizzDesign Staff – Page 7

Business analyst? Business Analysis & Design On Steroids!

September 8, 2013 by BizzDesign Staff

In a constantly changing world, with challenges for you as a business analyst ranging from big data, business intelligence/ analytics, BYOD and Lean/Six Sigma it is safe to say that business analysis is increasingly important for enterprise effectiven…

Influence vs. Force – Incenting others to get on board with your architecture initiatives

August 29, 2013 by BizzDesign Staff

Almost every architect has met the following frustrating experience during his career:A proper and well defined business case, architectural advice or Project Start Architecture is not being used by the organization the architect wanted to serve with …

Data management 8: Modeling

August 25, 2013 by BizzDesign Staff

This is the eight blogpost in the Data Management series. We have covered many capabilities that are associated with Data Management, ranging from Governance and Stewardship to Business Intelligence. In each posting we briefly touched upon the modelin…

Data Management 7: Business Intelligence

August 15, 2013 by BizzDesign Staff

This is the seventh blogpost in the Data Management series. After having covered basic terminology and key Data Management functions such as Master Data Mangement and Meta Data, we now zoom in on the field of Business Intelligence:TheoryBusiness Intel…

Data Management 6: Meta Data Management

July 24, 2013 by BizzDesign Staff

This is the sixth blog post in the Data Management series. In the previous post we zoomed in on Master Data Management (MDM). This time the focus shifts to Meta Data Management, or the art of keeping track of data about data.TheoryMeta data is often l…

Business Model Innovation webinar

July 22, 2013 by BizzDesign Staff

In the webinar Business Model Innovation for Architects and their Stakeholders we presented the Business Model Canvas as a relevant tool for Architects in many roles. Changing systems and processes alone is no longer enough in the rapidly changing env…

Data Management 5: Master Data Management

July 10, 2013 by BizzDesign Staff

This is the fifth blog post in the Data Management series. We have covered several basic topics so far. This time we zoom in on one of the sub disciplines of Data Management: Master Data Management.TheoryLoosely defined and following Loshins excellen…

Business Performance Management, Balanced Scorecards and The Decision Model

July 10, 2013 by BizzDesign Staff

The Decision Model (TDM) is a rapidly growing framework for modelling and executing the business logic behind business decisions. When I first read the book The Decision Model A Business Logic Framework Linking Business and Technology by Larry Goldbe…

The 1st Belgian ArchiMate User Group Meeting

July 7, 2013 by BizzDesign Staff

Last week I was proud to chair the first Belgian <a href=”http://pubs.opengroup.org/architecture/archimate2-doc/” style=”font-size: 11px; line-height: 19px;”>ArchiMate</a> User Group meeting in Brussels, hosted by <a href=”http://www.itworks.be/” style=”font-size: 11px; line-height: 19px;”>IT Works</a>. With three good speakers and a group of about 30 participants, the meeting was a big success. Hopefully we will have many more of such sessions in the years to come. In this short blogpost I’ll present some of the highlights from the session. Rather than attempting to summarize the excellent talks by Jan Casteels (AXA, ING), Geert Cannaerts & Christof Nikolay (both HP), and Pieter van Ostaeyen (de Lijn), I’ll stick to presenting some of the highlights.<ul><li>A common element in each of the three stories is “business-focused analyses”. Or, to put it differently: we spoke a lot about the type of analyses we can do for various (business) stakeholders as well as creating powerful visualizations to support decision making.</li> <li>The three speakers each used different tools (including <a href=”http://archi.cetis.ac.uk/”>Archi</a>, <a href=”http://www.sparxsystems.com.au/”>Sparx</a>, and <a href=”http://www.bizzdesign.nl/tools/architect/”>BiZZdesign Architect</a>). The consensus seemed to be that all tools work as long as the focus is on modeling / entry of concepts and relations. A “proper” tool like Architect is needed when the focus shifts to analyses (i.e., color views, label views, generating views and cross tables, roadmapping and so on)</li> <li>There was a lot of discussion about different levels of models. <ul><li>On the one hand this refers to the difference between “architecture” and “design” (i.e., growing attentions to linking architecture models at the enterprise level to process management, business rule management, and data management at the design level).</li> <li>It also appeals to the difference between three levels of abstraction: conceptual, logical, and physical models. A crisp and clear distinction between these levels is far from easy, yet it is important to at least distinguish (and create links) between a “conceptual/logical” model and a “physical” model of the enterprise</li> </ul></li> <li>Other topics that were briefly discussed include </li> <li>The use of reference models for re-use and a head-start in creating consistent models across the enterprise.</li> <li>Starting ArchiMate modeling projects from the bottom-up. That is: rather than shooting for a top-down, enterprise-wide initiative, we see more and more organizations where the first ArchiMate models are developed in projects. This has the added advantage of adding business value early, as well as establishing good practices in modeling from the start!</li></ul>After a good discussions, we also found several areas where more support and guidance would be useful for the ArchiMate community at large. These boil down to the following:<ul><li>Easy exchange of models between tools: we see that different stakeholders and groups of professionals require different types of tools. At some point the necessity to integrate these models / to upgrade to a full-blown EA tool like Architect arises. Being able to seamlessly switch between tools is important. After all, it is about the content, not the tool.</li> <li>In line with the discussion on different levels of models, more guidance on conceptual / logical / physical modeling as well as tool support (i.e., the use of dependency relations in BiZZdesign Architect) will help the community to deal with this issue consistently and effectively</li> <li>Last but not least: in many situations it would be valuable to be able to represent the modality of relations between concepts. This goes for “cardinality” of associations, but it goes further than that. Being able to represent the fact that “a process always uses a services” versus “a process may optionally use a service” can be equally important</li></ul> All in all a great session with plenty of tips, real-world stories, and suggestions for taking ArchiMate initiatives to the next level.

Infrastructure Architecture: What does that infrastructure box do?

July 1, 2013 by BizzDesign Staff

<h2>I can’t tell you what the box does…</h2>In my <a href=”http://www.bizzdesign.com/blog/infrastructure-architecture-function-before-construction/”>previous blog</a>, I outlined <a href=”http://www.bizzdesign.com/blog/infrastructure-architecture-function-before-construction/”>how infrastructure architects are better off focusing on behaviour instead of construction</a>. This, however, immediately leads to a curious problem: most folks in infrastructure are familiar with the offerings of the big vendors (at least up to a point), but very few can accurately describe what the products actually do. It’s typical for technical people: ask them what a product does, and they’ll tell you how it works.<img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Infrastructure-Architecture-OIAm-box.jpg” style=”width: 250px; height: 204px; float: right;”/>As a little self-test: what does the engine in your car actually do? Can you accurately describe its function? If you know something of automotive technology, you may find you’re tempted to explain the engine to me as an internal combustion device that burns fuel and thus converts the energy into motion; pistons, cylinders, valves or injection, all that stuff. But “burning fuel” is not actually the goal of having the engine in your car, is it?The same applies to infrastructure facilities: if you point to a box, its administrators can tell you how it is connected, how it is configured, and what cool features the vendor has created that they were able to use. But the language the admins use will likely be rife with buzzwords and proprietary terms that the vendor has made up, or has twisted in a <a href=”http://www.authorama.com/through-the-looking-glass-6.html”>Humpty-Dumpty</a> way (“When I use a word, it means just what I choose it to mean – neither more, nor less”). This serves the vendor well, because to retain these proprietary features, the best product to augment or replace his box will almost automatically be another one of his own boxes. But infrastructure architects shouldn’t want to limit their choices this way.<h2> … but I can tell you how it works.</h2>If we look again at your car’s engine, its function is to <a href=”http://en.wikipedia.org/wiki/Propulsion”>propel</a> the car. Other functions that are performed by different car parts: breaking, steering, signalling, lighting, offer seating, protection against impact, protection against the climate, et cetera. As our culture has had over a century of experience with automobiles, these different functions are easily recognized. (And you therefor probably already gave the proper answer in the previous self-test). Now if we look at infrastructure facilities, we find there are many words that describe the construction and its components (router, firewall, CMS, server, hypervisor, database), but we seem to lack the proper functional vocabulary. One could wonder if we could simply put “ing” behind a construction items name to describe its function. When we try that, we find that “Routing” and “firewalling” seem OK. But “Content Managing”, “serving” and “data basing” are too generic, and “hypervisoring”… well that doesn’t seem to mean anything. And by the way, doesn’t your firewall also do other things, like routing and logging? It’s clear we need to look at infrastructure in a different, more fundamental way. At the most basic level, we could say that infrastructure transports, stores, and/or processes a customer’s data. But using a vocabulary of only three verbs won’t get us very far, so we need more specific words to describe infrastructure functionality.<h2> The OIAm functional vocabulary</h2>Fortunately we don’t have to make up these infrastructure functions from scratch. There’s a community surrounding the Open Infrastructure Architecture method (OIAm), that has been working on this problem of recognizing and naming infrastructure functionality since 2008. This has resulted in a list of some <a href=”http://www.infra-repository.org/oiar/index.php/Building_Block_Type_Overview”>fifty-plus infrastructure functions</a>, ranging from “distribution” (what a router does) and “filtering” (what a firewall does) to “interconnection” (long range network connection), from “Application Engine” to “Identity Validation”, et cetera. Tested in practice, the set of infrastructure function covers just about everything that the infrastructure architects need to describe. One thing that remains difficult, however, is how to come to acceptable names for the functions. We’ve found cases where a function was named with a seemingly fitting, industry accepted term, only to find that architectures containing this function were misunderstood by some, precisely because of that familiar term. Examples are Authentication (now named Identity Validation) and “Basic Storage” (now Raw Retention). It turns out that many recognizable terms can be interpreted in many different ways, some narrow in interpretation, others quite sweeping. On the other hand, if functions are named with seemingly abstract, obscure, or otherwise unknown terms, then some stakeholders may regard the whole architecture built on those functions as a fairly useless academic exercise. So in naming generic infrastructure functions, we need to maintain a precarious balance between terms that are too familiar, and terms that are too alien. Have the community succeeded in this? Maybe you can <a href=”http://www.infra-repository.org/oiar/index.php/Building_Block_Type_Overview”>have a look</a> for yourself, and if you think you can help us improve, feel free to <a href=”mailto:j.schoonderbeek@bizzdesign.nl”>drop me a line</a>. And since the vocabulary is published under a Creative Commons license, you are free to use it as you see fit.

EA Roadmap for success: Wrap up

June 20, 2013 by BizzDesign Staff

This posting wraps up our blog series on Enterprise Architecture implementation. In the series we described our experiences with implementing enterprise architecture, and how to be successful with that. We followed a step wise structure: Aim, Establish, and Execute. The structure and the postings that are part of this series are depicted in the figure below.<img alt=”Roadmap for success” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130508_EA-Roadmap-for-success-Wrap-up/Roadmap-for-success-wrap-up.png” style=”width: 676px; height: 422px;” title=”Roadmap for success: Final blog”/><h2>Roadmap for success: an overview</h2>Enterprise architecture can be a powerful tool, mostly if an organization has clear ideas and plans as to how enterprise architecture is going to deliver value to the organization. We described that enterprise architecture can benefit an organization in many ways, and that there are several approaches, the extremes being the top-down and bottom up approach. In a top-down approach enterprise architecture helps the organization plan for change on a more strategic level. In a bottom-up approach enterprise architecture can achieve better coordination and coherence among projects and application portfolios by leveraging enterprise architecture practices such as standards and principles. Whatever the approach is, enterprise architecture can never operate in isolation. enterprise architecture processes need to be explicitly aligned with other processes and frameworks in the organization. Often, implementing enterprise architecture is more about reusing, coordinating and leveraging existing processes, rather than introducing exclusively brand new ones. For the task of coordinating enterprise architecture work, the Architecture Board plays an important role. The way in which the architecture board should be organized and operate differs somewhat depending on the approach that the organization takes (<a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-top-down-versus-bottom-up-architecture/”>i.e. top-down or bottom-up</a>) describes all the details.There are a number of Enterprise Architecture frameworks that could be used by an organization as a starting point for the organization specific enterprise architecture framework. These frameworks differ in scope and level of detail. We think the TOGAF standard (The Open Group Architecture Framework) is very complete, especially when combined with ArchiMate (also by the Open Group). ArchiMate can be used to model the Enterprise Architecture. Using ArchiMate, the viewpoints for various stakeholders as described in the TOGAF standard can be created. Independent of what framework an organization chooses it is of importance to tailor it to organization specifics. The framework should never be the goal in itself.In the establish phase we covered a number of aspects such as project based implementation, how to <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-establish-an-enterprise-architecture-team/”>establish the team</a>, <a href=”http://www.bizzdesign.com/blog/enterprise-architecture-roadmap-for-success-tooling/”>what tools</a>(e.g. modeling tools) to use, and whether or not to use <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-consultants/”>consultants</a> to assist in the establishment of the enterprise architecture practice in the organization. Very important is, especially since the word enterprise architecture often comes with humongous expectations, to make sure that enterprise architecture implementation is broken up into pieces that the organization can absorb. We talk rather about evolution of the enterprise architecture practice, where an organization builds the enterprise architecture practice from the situation today, gradually introducing more enterprise architecture tasks and expanding scope and footprint. This approach lets the organizations enterprise architecture maturity grow steadily.So trying to boil the ocean often does not prove to be a successful strategy for enterprise architecture implementation, following a sustainable growth path does.In the last section of the series we covered concrete aspects of doing EA, such as defining <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-architecture-principles-and-models/”>architecture principles and modeling</a>, <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-governing-projects/”>project governance</a>, and <a href=”http://www.bizzdesign.com/blog/ea-roadmap-for-success-capability-based-planning/”>capability base planning</a>.<h2>Learn more</h2>We think we touched upon important aspects of enterprise architecture implementation throughout this series. Of course there is a lot more to learn about Enterprise Architecture, implementation, modeling etc. BiZZdesign offers a number of courses on these subjects, for example training and certification in TOGAF and ArchiMate. Please see our web site for more information and dates. Also, we frequently run webinars on enterprise architecture and other topics in the Business Design field. Dates and more information can also be found on our website: <a href=”http://www.bizzdesign.com”>www.bizzdesign.com.</a><h2>Contact us</h2>If you’d like to know more, please contact the authors directly at <a href=”http://b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a href=”http://s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment.

Data Management 4: Data Stewardship

June 17, 2013 by BizzDesign Staff

This is the fourth blog post in the Data Management series. So far we have discussed Entities and the way they are realized in applications / information systems. This time we zoom in on Data Stewardship.<img alt=”The fourth blog in the Data Management series” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-management-stewardship.png” style=”width: 501px; height: 334px;” title=”Data Management part 4: Realization of Entities in applications”/><h2 class=”p1″>Theory</h2>The Data Steward is a key role in successful Data Management. To put it more strongly, we will argue that without a Data Steward (or Steward, in short) most Data Management initiatives are doomed to fail. <img alt=”Data Steward. Data Management” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-management-data-steward.png” style=”width: 251px; height: 188px; float: left;” title=”The Data Steward is a key role in successful Data Management”/>The steward is an organizational role. The professional tasked with this role is typically responsible for data quality of the Entities in a Subject Area from a business perspective (in a recent talk at the Master Data Management/Data Governance summit in London, Analiese Polsky of SAS mentioned five models for stewardship. However, stewardship aroundinformation areas is still the predominant approach which is why we adopt it here).In some cases a Subject Area is too large for one Steward to manage, and therefore it becomes a joint responsibility of a group of Stewards.The Steward works with Data Professionals (i.e., IT staff) to make sure those requirements with respect to data are realized in an effective manner. Typical tasks for the Steward are: data modeling, data definition, data quality requirement specification and data quality improvement, reference and master data management. It should be noted that a Steward is not a technical role. On the contrary: it is a prototypical business role. Deep business knowledge is essential to be able to articulate business needs with respect to information, and to negotiate the priorities with fellow stewards and IT, resolve conflicts in semantics, budget, and availability of staff etcetera.In order to co-ordinate the work between data stewards, many organizations typically have a Data Council at the Enterprise level. This is where alignment issues are resolved and where strategic decisions with respect to data management are made. If necessary (especially in larger organizations), a level of stewardship can be created in between as illustrated by the following diagram that was taken from the <a href=”http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/”>DAMA DMBOK</a>:<img alt=”DAMA DMBOK Data Management” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130618_BasvanGils/Data-Management-stewardship-DAMA-DMBOK.png” style=”width: 699px; height: 484px;” title=”Stewardship can be created in combination with the DAMA DMBOK”/><h2 class=”p1″>Modeling</h2>This topic does not require a lot of specialized modeling constructs. The most important one is to be able to represent the fact that a Steward is responsible for a Subject Area / Entity / Data Object. The standard way of modeling would involve a BusinessRole for the Steward, assigning it to a BusinessProcess that has access to the relevant passive structure elements. In terms of visualization this is often too complex. We have found that a shorthand notation where a BusinessRole (the Steward) is associated to the BusinessObject (for SubjectArea or Entity) or DataObject works well for communication purposes. The Data Council can be regarded as a body where stewards collaborate. This should be modeled using the BusinessCollaboration concept using standard ArchiMate notation. To avoid visual complexity, visual nesting (drawing stewards inside the council) is preferred over using graphical relations (i.e., drawing a line between the concepts). In terms of analysis there are some interesting things we could do:<ul><li class=”li1″>Select a Steward and generate a view with all Entities and associated Data Objects that s/he is responsible for</li> <li class=”li1″>Select a Steward and highlight (color? Highlight view?) the Entities and Data Objects that s/he is responsible for</li> <li class=”li1″>Generate a matrix-view that shows Stewards on one axis, Entities on the other axis and the names of the associated Data Objects at the intersection</li> <li class=”li1″>Generate a matrix view that shows Stewards on one axis, Entities on the other axis, and Systems that manage (the C, U, D parts) a Data Object that realizes this Entity in between. </li> <li class=”li1″>Select an Entity or Data Object and highlight (color? Highlight view?) the Steward who is responsible for it</li> <li class=”li1″>Select a System and show with labels which Data Objects are managed in that system, and who the associated Steward is. A format could be “Steward: AAA – DataObject: BBB” </li></ul>Doing this type of analysis is fairly straight forward in most modern ArchiMate tools If you are interested in a demo of this type of functionality in BiZZdesign Architect, please leave us a note!The next posting will be about Master Data Management, one of the corner stones of the field of Data Management. It is often said that “You can do data governance without Master Data Management. You can also do Master Data Management without Data Governance, but that would be a bad idea”. An exciting topic, so stay tuned!