Search Results for “archimate” – Page 40

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!

Enterprise Architecture Roadmap for success: Capability Based Planning

June 13, 2013 by BizzDesign Staff

This is the 12th posting of the enterprise architecture Roadmap for success blog series, before we wrap it up with an overview in the last posting. We have covered a wide range of topics so far, in this posting we zoom in on one of the most useful techniques in the field of strategic enterprise architecture planning: capability based planning.<div class=”captionImage leftAlone” style=”width: 337px;”><div class=”captionImage leftAlone” style=”width: 600px;”><img alt=”Capability Based Planning” class=”leftAlone” height=”375″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600375-Roadmap-for-success-capability-based-planning.png” title=”12th posting in the roadmap for succes series” width=”600″/>Part 12: Capability Based Planning</div></div>Capability based planning<img alt=”Capability Based Planning” class=”left” height=”139″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage150139-capability-based-planning.png” title=”It may take a long time to realize the architecture” width=”150″/>There are many ways to look at architecture as we have seen in this blog series. Generally, architectures of systems (in the broadest sense of the word) are fairly high level and focus on the fundamental organization of the system as well as principles underlying this fundamental organization.Especially for complex systems, it may take a long time to realize the architecture. Or, to put it in a different light, organizations may be smart and to cater for the fact that their long-term vision may change, deciding to take it one step at a time, allowing for the vision / architecture to change. This also takes into account the fact that organizations already have certain capabilities that they may wish / need to develop further in an incremental fashion. This is where Capability Based Planning kicks in.<h2>Capability Based Planning – the TOGAF™ way</h2>Many definitions for capabilities (and frameworks around capabilities) have been proposed and used in practice. In this post we zoom in on the TOGAF-framework which is fairly well aligned with other capability frameworks. The TOGAF-standard has two definitions for the term Capability, which can loosely be paraphrased with the statement “A capability is an ability that an organization, person, or system possesses”. Capabilities are typically ‘horizontal’ in the sense that they span many lines of business as is illustrated by the figure below (from <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard), but that is not always the case.<img alt=”TOGAF and Capability Based Planning” class=”leftAlone” height=”333″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600333-TOGAF-framework.png” title=”The TOGAF-standard has two definitions for the term Capability” width=”600″/>Two capability definitions in TOGAFThe idea is that an organization’s capability may be at a certain ‘level’ at some point in time. In order to further that capability – conform the Architecture Development Method – a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) before it is actually implemented:<img alt=”Capability, Architecture, Solution model” class=”leftAlone” height=”193″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage600193-Screen-Shot-2013-04-26-at-11.32.44-.png” title=”a new architecture is developed (using e.g. ArchiMate), which is fleshed out in more detail in a solution model (e.g. ArchiMate, UML, BPMN) ” width=”600″/>Another important aspect of capabilities lies in the fact that they may have different ‘dimensions’. For example, <a href=”http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html” target=”_blank”>Chapter 32</a> of the TOGAF standard lists a people dimension, process dimension, and material dimensions for a given capability. In other words, when planning the next increment for our ability (i.e., the goal we want to achieve for this increment in the next ADM cycle), we should consider the ramifications for each of these dimensions.<h2>Modeling support</h2>Given the integration between ArchiMate® and TOGAF™, we feel that capability based planning also deserves proper modeling support. We are working on a simple meta-model to support capability based planning, the core of which looks like this: <img alt=”Capability based planning. A meta model” class=”leftAlone” height=”301″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/core-modeling-ArchiMate-TOGAF.png” title=”meta-model to support capability based planning” width=”422″/>This sample shows that capabilities may have one or more dimensions, and are realized by one of more increments, indicative of the different points in time. These increments are still conceptual in nature, and indicate points in time. Each increment may be realized by an architecture, expressed as a set of core concepts (<a href=”http://www.bizzdesign.com/blog/archimate-core-overview/” target=”_blank”>see our series on ArchiMate</a>). Using this simple meta-model we can create the following view:<img alt=”Capability with 5 different dimensions” class=”leftAlone” height=”299″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage500299-core-concepts-meta-model-ArchiMate-TOGAF.png” title=”Each increment may be realized by an architecture, expressed as a set of core concepts” width=”500″/>Here we see a capability with 5 different dimensions. In each of the four increments, the capability has a certain value that indicates ‘how good we are doing with respect to this capability’. As the analysis of this diagram may be hard, we propose a simple radar view as follows:<img alt=”radar view of capability” class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/customer-dimension-capability-increments.png” title=”Capability radar view” width=”350″/><h2>Use in practice</h2>In our experience, Capability Based Planning as a technique can be used in a many different settings. The main benefit of this approach lies in the combination of easy communication (capability is a term that management tends to understand well) while still allows for formal modeling and analysis. We have used it successfully in helping one of our clients in furthering their data management practice, linking the technique of capability based planning with the DAMA DMBOK framework. The DMBOK framework decomposes the data management capability into several sub capabilities such as data governance, master data management, Business Intelligence and so on. It also proposes to consider each capability from different dimensions which may lead to an assessment such as:<img alt=”Capability assessment” class=”leftAlone” height=”270″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130426_ea-roadmap-for-success/_resampled/resizedimage450270-DAMA-DMBOK-framework.png” title=”such diagrams communicate well and provide a solid basis for further analysis and realization” width=”450″/>Indeed, such diagrams communicate well and provide a solid basis for further analysis and realization (which steps will we take? When? What is the architecture that goes with each of these steps? How does this translate to projects that take us to the next level?).<h2>Next posting</h2>If you’d like to know more, please contact the authors directly at <a href=”mailto:b.vangils@bizzdesign.com” target=”_blank”>b.vangils@bizzdesign.com</a> / <a href=”mailto:s.vandijk@bizzdesign.com” target=”_blank”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next wraps up the series! It is scheduled to between 6th and 10th of May.

Data Management 3: Realization of Entities in applications

June 11, 2013 by BizzDesign Staff

This is the third blog post in the Data Management series. Last time we discussed the notion of subject areas and entities. This time we zoom in on the realization of these entities in applications.<img alt=”Content. Data Management part 3″ src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-realization-of-entities-in-applications.png” style=”width: 501px; height: 334px;” title=”Data Management part 3: Realization of Entities in applications”/> <img alt=”Data Management. Coverage analysis” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-Coverage-Analysis.jpg” style=”width: 150px; height: 114px; float: left;” title=”A “coverage analysis” will be the tricky part”/>One of the things we should be able to do is to create views that show which systems have data about a certain Entity. Similarly, we want to link our Entities to Processes. Going forward, we will use the term ‘Data Object’ to differentiate between the Entity in a business context and its data-counterpart. The ‘Attributes’ of Entities (see also our previous post), are reflected as ‘fields’ in their Data Object counterparts. A “coverage analysis” will be the tricky part: suppose that we have a Subject Area called ‘Customer’. The key Entity in this Subject Area is also called Customer with Attributes such as name, social security number etcetera. Other Entities are such things as shipping address, E-mail address, etcetera. There are two things we want to visualize for business stakeholders: <ol class=”ol1″><li class=”li1″>Which information with respect to a customer is relevant from a process perspective? Only name? Only Social Security Number? Both?</li> <li class=”li1″>Which information about a customer is stored in a system? One system may store the E-mail address of a customer, whereas the physical address may sit in another system</li></ol>We have call this a “coverage analysis” because: from a data governance perspective we want to make sure that all Entities in a Subject Area, as well as all Attributes of an Entity are represented somewhere in a System!This type of modeling is quite ‘standard’ in ArchiMate. There are separate concepts for BusinessObjects and DataObjects. Also, there is a standard way of relating the two, using a RealizationRelation. The fact that DataObjects have Fields is modeled using a CompositionRelation and more DataObjects. This is not a very ‘pretty’ solution. Especially when a data object has many fields, the visualization will quickly become cluttered. For example, 4 DataObjects with 3 Fields each ads up to at least 12 concepts and 12 relations which has a high visual complexity. Using graphical nesting will result in a much cleaner visualization.The standard way of modeling the relation between a system (ApplicationComponent) and a DataObject uses the behavioral concept of an ApplicationFunction. The idea is that an ApplicationComponent has (internal) behavior to manipulate DataObjects. While it is correct, and often useful to model Application Functions, for most visualizations it is equally useful to hide them and use a short-cut notation as follows:<img alt=”A model of application functions” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130611_BasvanGils/Data-Management-model-application-functions.png” style=”width: 599px; height: 262px;” title=”model Application Functions”/>With respect to the coverage-type analyses mentioned previously, this could be done and visualized in many different ways such as:<ul><li class=”li1″>Select a Subject Area or an Entity and list (color view) all Data Objects that are associated with it</li> <li class=”li1″>Select a Subject Area or an Entity and show (color view) all Systems that manage a data object that is associated with this Subject Area or Entity. </li> <li class=”li1″>Select a Subject Area and highlight (color view) the entities that have an associated Data Object that is managed by some system</li> <li class=”li1″>Generate a CRUD-matrix that lists which Entities are accessed by which Process. Use the CRUD notation in the cells to show the nature of the access relation</li> <li class=”li1″>Select a Subject Area and create a CRUD-matrix as listed above</li> <li class=”li1″>Select a Subject Area and create a CRUD-matrix that shows which System manages (!) a Data Object that is a realization of an Entity that sits in that Subject Area. At the intersection of the columns and rows we should list the name of the Entity</li></ul>Modern tools such as BiZZdesign Architect make these analyses fairly straightforward and reusable. We mentioned techniques such as creating color views and generating tables. This functionality is available in our Enterprise Architecture tool BiZZdesign Architect, which can be downloaded here (30-day free, fully featured, trial license). If you would like a demonstration, please leave us a note!As a final thought for this posting: note that this list has a mix of different types of visualizations, such as diagrams and matrices. This is partly because of communication preferences of key stakeholders, but also because some results are easier to interpret in different formats. In the next posting we will dive into Data Governance with a strong focus on data stewardship (Data Stewards are generally considered to be the heroes of the field), so stay tuned!

Experts of the Enterprise Architecture World

June 11, 2013 by Ed Jones

The practice of Enterprise Architecture is a dynamic and constantly evolving world. To ensure you remain at the very pinnacle of the practice and keep your knowledge current, we’ve gone about collating some of the leading minds within Enterprise Architecture bubble (many of whom can be found on EA Voices). So dust off your bookmarks, …

Open Group TweetJam on ‘Platform 3.0′

June 7, 2013 by Tom Graves

A quick ‘public-service’ blog-post to document a possibly-useful conversation for enterprise-architects and others. Yesterday (6 June 2013) The Open Group ran a ‘tweet-jam‘ online-conversation, to: examine how convergent technologies such as Big Data, Social, Mobile and The Internet of Things are…

Gartner EA Conference Summary in Top Influential Tweets

June 6, 2013 by Mike Walker

I usually don’t post recaps of events in their tweets but since I was unable to do full coverage of the event I have picked out what I thought to be the most influential tweets. Lots of good nuggets from…

A Different Open Group Enterprise Architecture Conference in 2013

May 30, 2013 by Mike Walker

This year the Open Group is doing something very different with their conference from previous years, they are verticalizing. Smart move. With all the talk about business centric Enterprise Architecture this is a smart direction on the Open Group’s part….

Data Management 2: Subject Areas and Objects

May 23, 2013 by BizzDesign Staff

This is the second blog post in the Data Management series and we will dive straight in with a discussion about subject areas and (information) objects, often called Entities. We start with a high-level overview of the theory and then dive into ArchiMate modeling.<img alt=”Subject Areas and Objects. Data Management blog series” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-subject-areas-objects_424x283.png” style=”width: 424px; height: 283px;” title=”Data Management blog series. Part: Subject Areas and Objects”/><h2 class=”p1″>Theory</h2>A subject area model is used to differentiate between areas of interest from a data/ information perspective in the organization. These are called Subject Areas. Examples of subject areas are: customer, product, and supplier. This is not a new concept; it seems that it was introduced by James Martin in his books on Information Engineering in the late 1970s/ early 1980s. A Subject Area typically consists of 12-20 Business Subjects. These are the key areas of interest in the business domain. Simplifying slightly from the <a href=”http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/” target=”_blank”>DMBOK</a> best practice, we use the concept of an Entity as a synonym for a Subject. Note that in fact we are talking about Entity Types rather than Entities (see the work of <a href=”http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215/” target=”_blank”>Kent</a> for an extensive discussion of why this distinction is important). We focus on the type level, not the instance level. For purposes of readability, we will consistently use the term Entity rather than Entity Type. The following ORM diagram illustrates this point:<img alt=”Entity types related by means of a fact type” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/data-management-entity-types.png” style=”width: 202px; height: 110px; float: left;” title=”Two Entity Types (Person and Company) related by means of a fact type (“works for” with the inverse reading “employs”).”/>Here we see two Entity Types (Person and Company), each identified by their na,e. These are related by means of a fact type (“works for” with the inverse reading “employs”). The purple dot signifies the constraint that “each Company employs at least one Person”The population of this scheme in terms of Entities is visualized by the supporting table. Here we see for example that the label “Bas” identifies an Entity of the Entitiy Type “Person”. Business Entities are the ‘things’ we talk about in a business context. For example, the Subject Area ‘Customer’ would be decomposed in Entities such as customer, address, and purchase history, etcetera. One would typically make an ERD to show the relations between entities as well as constraints on these entities (for each order the customer supplies a shipping address and a billing address). This may be a bit too much at the architecture / ArchiMate level, but we should at least be able to tie in to an ERD.<h2 class=”p1″>Modeling</h2>In summary: we introduced and defined two concepts for information modeling that we will be using throughout this blog post series: <ul><li class=”li2″>Subject Areas, which are used to structure areas of interest from an information perspective, for example customer, or product; and,</li> <li class=”li2″>Business Entities (or just short: Entities), which are the key concepts or “things” that are part of a Subject Area, e.g. for the Subject Area customer: address or purchase history;</li></ul>In this part we describe how these concepts could be modeled in ArchiMate. This makes it possible to integrate model support for Data Management into the overall Enterprise Architecture expressed in the ArchiMate standard. Also, tool support such as BiZZdesign’s modeling and analysis tool for Enterprise Architecture, BiZZdesign Architect, can be leveraged for Data Management. It seems to make sense to model the Subject Area concept with the BusinessObject concept. In BiZZdesign Architect, we could add a profile to this concept so that we can distinguish them from regular BusinessObjects in the sense that they could have a different graphical shape. Along the same lines: Entities should be modeled using the BusinessObject concept. This does not require any further profiles, except for cases where the model also captures other types of business objects (i.e., non-informational objects) and we want to be able to distinguish between the two types. Two challenges remain:<ol class=”ol1″><li class=”li1″>Entities have Attributes. It may be very important to be able to represent the fact that we distinguish between “first name” and “last name” rather than simply using “name”. Since ArchiMate does not have a concept for Attribute, we propose to simply use a CompositionRelation to decompose BusinessObjects into its attributes. Domains, cardinality and optionality are not modeled at the ArchiMate level.</li> <li class=”li1″>Many organizations choose to explicitly model meta-data about Entities. For example: definition of the concept, relevant business rules and legislation, stewardship (as we will describe in a later posting) and so on. It seems to make sense to use the ‘Meaning’ concept for this. However, this quickly becomes tedious and will crowd the model. Also, some meta-data is represented by the fact that BusinessObjects are linked to other ArchiMate concepts in the model. We will get back to the meta-data discussion in a separate post! </li></ol>To provide a link with the design level, it makes sense to relate Subject Areas to more detailed ERD models. To do this, we have recreated the basic Chen ER diagramming notation as a separate meta model in Architect which allows us to do the following:<ul><li class=”li2″>A Subject Area as modeled in the ArchiMate world is refined in an ERD view</li> <li class=”li2″>An Entity as modeled in the ArchiMate world is equal to an entity in an ERD view</li></ul><img alt=”Subject area and entity modelled in ArchiMate ” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-ArchiMate-model-package_599x274.png” style=”width: 599px; height: 274px;” title=”Subject Area as modeled is refined in an ERD view in ArchiMate. An Entity is equal to an entity in an ERD view in ArchiMate”/>In the next posting in this series we will describe how entities are realized in applications. As always: if you have questions or suggestions, please drop us a note. Stay tuned!

NOTES – an alternative approach for EA

May 21, 2013 by Tom Graves

If – as we’re often told – business-design is about the relationships between people, process and technology, what is it that links all of themes together? Answer: a story. Okay, yes, this is a theme I’ve explored a lot here on…

Implementation-independent design of business logic, integrated with business processes and information

May 16, 2013 by BizzDesign Staff

BiZZdesign has a long tradition in model-based design and improvement of organizational processes. Building on this tradition, we have extended our portfolio with a method and tool for implementation-independent design and analysis of business logic, which seamlessly integrates with business process and information design.<h2 class=”p1″>Why yet another modeling domain?</h2>A problem that many organizations are facing is that the rules originating from legislation or business policies eventually end up in many different places in the organization, with many opportunities for misinterpretation along the way. The resulting business logic is hidden in business processes or hard-coded in software, which makes it very inflexible and hard to manage. Although most of the current business rules approaches promise to offer a solution to this problem, by “separating the know from the flow”, this promise is often not fulfilled, due to a number of reasons:<ol><li>There is still a lot of confusion as to what a business rule actually is, and what different types of business rules exits.</li> <li>Business rules are often specified in a very detailed way, in one of the proprietary languages of a rule engine. As a result, they usually have a technical 'technical’ flavor, which makes it difficult for business stakeholders to verify them, and they are tied to a specific implementation platform.</li> <li>Business rule specifications, and the tools that support them, are often poorly integrated with the existing process and information models and tools.</li></ol>When modeling your business logic, business processes and information as separate, coequal domains, loosely coupled through a limited set of linking elements, the resulting designs become much more flexible and manageable. By first specifying them in an implementation-independent way, it becomes easier to verify whether a design actually meets the requirements of the business. And once there is agreement on the correctness of the design, different implementations can be derived from it.<h2>Towards an integrated design</h2>As illustrated in the picture below, your business processes, information and business logic can be developed in separate design ‘flows’, in an arbitrary order; but ultimately, these flows will have to come together, to form an integrated design of your organization:<img alt=”The integration of Decisions, Processes and Information” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/Integrated-decision-modelinglegenda.jpg” style=”width: 607px; height: 550px;” title=”Integrate Decisions, Processes and Information”/>For the implementation-independent design of business processes, we use our proprietary modeling language Amber or the BPMN 2.0 standard. For information modeling, a wide variety of formalisms is available, e.g., Entity Relationship diagrams or UML class diagrams. To complete the trio, we have adopted The Decision Model, as described in the book “The Decision Model: A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg, as our language of choice for designing the business logic. This approach turned out to be perfectly suited for our purpose. It matches a simple graphical notation to model the decision structure with an intuitive tabular specification of the business logic and a rigorous set of integrity principles. Moreover, it can be combined with business process models and information models in a natural way.<h2>The Decision Modeler</h2>On June 11th, we will launch <a href=”http://www.bizzdesign.com/tools/the-decision-modeler/”>The Decision Modeler</a>, our software tool a tool for implementation-independent modeling and analysis of business logic based on The Decision Model. Because the tool is part of the BiZZdesign design suite, decision models can be linked to other models in this suite, including business process and information models, but also enterprise architecture models and requirements models in the ArchiMate language.The figure below summarizes how the different elements of a decision model in The Decision Modeler are related to each other, and to element from process and information models.<img alt=”” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/The-Decision-Modeler-relations.png” style=”width: 600px; height: 468px;” title=””/>In my next blog in this series, I will give a more in-depth description of the concepts and functionality of The Decision Modeler, and apply the approach described here to a real-life example. In the meantime, if you have any questions or suggestions, please send me an e-mail on <a href=”mailto:h.jonkers@bizzdesign.com” target=”_blank”>h.jonkers@bizzdesign.com</a>, or add a comment below.

Data Management: Introduction

May 5, 2013 by BizzDesign Staff

The topic of Data Management (DM) is increasingly important for many organizations. Much has been researched and written in this field, both from a business and a technical perspective. For example:<ul><li><a href=”http://www.amazon.com/The-Data-Asset-Companies-ebook/dp/B002JMV6LY”>The Data Asset</a> by Tony Fisher presents a strong argument for considering data from a business perspective and argues the case that quality data is quintessential for sustainable business success</li> <li><a href=”http://www.amazon.com/Master-Data-Management-Press-ebook/dp/B001FA0HAM/”>Master Data Management</a> and <a href=”http://www.amazon.com/Practitioners-Guide-Quality-Improvement-ebook/dp/B004HD63OS”>The Practitioner’s Guide to Data Quality Improvement</a> by David Loshin provide an excellent technology independent overview of several key aspects of data management with attention for business and technology concerns</li> <li>The <a href=”http://www.amazon.com/Management-Knowledge-DAMA-DMBOK-Portuguese-Edition/dp/1935504177/”>DAMA DMBOK</a> is considered to be the most comprehensive overview of the field of data management in existence</li></ul>It is increasingly recognized that enterprise architecture (EA) models are a valuable tool in this field. At the recent MDM/DG summit, hosted by IRM UK, (see also our previous <a href=”http://www.bizzdesign.com/blog/mdm-dg-summit-recap/”>blogpost</a>) it was agreed that:<ul><li>Architects and Data Management Professionals often talk to the same stakeholders</li> <li>Share a common mindset, tools,and models</li> <li>Tackle similar issues</li></ul>Given BiZZdesign’s proposition in this field with ArchiMate and Architect, it makes sense to investigate how ArchiMate can be leveraged in the field of Data Management – at least from a modeling perspective. Obviously, the Data Management -space covers much more than models but that is beyond the scopeof this series. This subject is too large to tackle in one go though, so we follow an incremental approach and tackle various aspects one by one, as depicted in the figure below:<img alt=”Data management. Incremental approach” id=”” longdesc=”An incremental approach to tackle various aspects one by one” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130506_Data-Management-Introduction/Data-Management-Incremental-approach.png” style=”width: 550px; height: 334px;” title=”An incremental approach to tackle various aspects one by one”/>For each aspect we will give a short introduction describing context and relevance, after which we explore the relevant modeling concepts and how they could be translated to ArchiMate:<ul><li>Subject Area & objects: an overview of how the information landscape can be subdivided into coherent subject areas, which can be decomposed into business entities</li> <li>Realization of Entities in applications: entities represent business concepts, and may be realized by some IT system. In this post we will show how to model this</li> <li>Stewardship: a steward is the person responsible for the quality of information, i.e. the entities that are part of a subject area</li> <li>Mastering data: many organizations have dispersed data about key entities. It is not uncommon for these versions to mismatch. Master Data Management (MDM) is about creating a master record for these key entities</li> <li>Meta Data: meta data is often defined as data about data. This is a broad discipline which covers various topics including business- and technical metadata</li> <li>Business Intelligence: is a discipline in its own right. Loosely defined it is the discipline that is concerned with providing management with the ‘intelligence’ necessary to run the business. It is often associated with such things as an Enterprise Data Warehouse.</li> <li>We end the series with:an overview of the relevant concepts from the ArchiMate metamodel and provide an idea of what advanced / custom visualization in this context would look like.</li></ul>Stay tuned for the next posting in which we dive into the “meat” of the series. If you have a question or suggestion, please leave a comment.