EA Voices – Page 683 – Aggregated enterprise architecture wisdom

Enterprise Architecture Cartoon!

June 14, 2013 by Rajeev Bhardwaj

An Enterprise Architecture Cartoon!! Informative and funny.. Enjoy :-)Credit: All credit goes to FlinchStudio who made this video (I think..)

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.

Whence, Angels?

June 13, 2013 by Aleks Buterman

As you’ve read over past couple of years, we’ve started investing in a hybrid Angel/VC model. Lots of risk, lots of upside, and lots of fun new things to learn. Applying Capability Driven Methods to management from the start has been both f…

Whence, Angels?

June 13, 2013 by Aleks Buterman

Emerging Technology and Disruptive Technology – What’s the Difference?

June 13, 2013 by Chris Curran

Some people question my use of the word “emerging” to categorize technologies such as social, mobile, cloud, analytics, sensors and others. They argue that these technologies are already here and aren’t emerging anymore. Some suggest using “disruptive” to describe them instead. Now is a good time to distinguish between these two labels and make sure that we are using each to help us better understand technology’s impact to our businesses. Emerging means to come into […]

If you liked this, you might also like:

So you have to transmit some files, huh?

June 12, 2013 by Steve Biondi

When was the last time you found yourself on a project that didn’t involve some degree of file transmission? No, that one doesn’t count… Ok, so maybe you occasionally have a solution that doesn’t require any file delivery but every architect worth his weight in .csv files is going to come across this task at […]

Maximize Value from CMDB by Integration

June 12, 2013 by Corey Balko

In part 4 of “Memoirs of an Enterprise Architect” I discussed the rules around defining an application as well as the 6 keys to successful Application Portfolio Management. In Part 5, I will discuss integrating with a Configuration Manage…

Don’t ban the word “alignment” from your architecture

June 12, 2013 by Adrian Grigoriu

Alignment though essentially means transforming the enterprise (technology for instance) to perform what the business needs on an operational, tactical and strategic scale.

Placing Architecture Properly into Scrum Processes

June 11, 2013 by Nick Malik

As I’m about to complete my share of a longer engagement on using Lean principles to improve the processes at an online services firm, it occurred to me that the efforts we undertook to properly embed Architecture practices into their Scrum process were novel. I haven’t seen much written about how to do this in practice, and I imagine others may benefit from understanding the key connection points as well. Hence this post.

First off, let me be clear: Agile software development practices are not at all averse to software architecture. But let’s be clear about what I mean by software architecture. In an agile team, most decisions are left to the team itself. The team has a fairly short period of time to add a very narrow feature (described as a user story) to a working base of code and demonstrate that the story works. The notion of taking a couple of months and detailing out a document full of diagrams that explains the architecture of the system: pretty silly.

The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie? Will a layered paradigm be used, and if so, what are the responsibilities of each layer? What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components? How will the modules be deployed at scale? How will information flow among the modules and between the system and those around it?

The way these questions are answered will indicate what the architecture of the system is. There are many choices here, and the “correctness” of any choice is a balance between competing demands: simplicity, security, cost, flexibility, availability, reliability, usability, correctness, and many more. (These are called “System Quality Attributes”). Balancing between the system quality attributes takes thought and careful planning.

So when does this happen in an agile process?

Let’s consider the architect’s thinking process a little. In fact, let’s break the software architecture process into layers, so that we can divide up the architectural responsibility a little. You have three layers of software architectural accountabilities. (Repeat: I’m talking about Software Architecture, not Enterprise Architecture. Please don’t be confused. Nothing in this post is specific to the practice of Enterprise Architecture). All this is illustrated in the diagram below. (Click on the diagram to get something a little more readable.

At the top, you have the Aligning processes of software architecture. These processes consider the higher levels of enterprise architecture (specifically the business and information architecture) to create To-Be Software Models of the entire (or relevant) software ecosystem. If you’ve ever seen a wall chart illustrating two dozen or more software systems with connectors illustrating things like flow of data or dependencies, you’ve seen a model of the type I’m referring to. Creating and updating these kinds of diagrams is a quarterly or semi-annual process and reflects the gradual changes in the strategy of the enterprise.

In the middle, you have the Balancing processes of software architecture. These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment. All of this can be conveyed in a fairly short document that is rich in diagrams with a small amount of text explaining the choices. This occurs once when a system is moving forward, and the software architecture can be developed alongside the first couple of sprints as input to the third and subsequent sprints.

At the bottom, you have the Realization processes of software architecture. This is where the architecture becomes software, and this is where decisions are made about the choice of specific design patterns, the appropriate level of configurability vs. simplicity, and the ability to demonstrate whether the actual intent of the architecture occurs in practice. In agile, this layer occurs within the team itself. The software architect can offer advice about what patterns to use, but it is up to the team to realize that advice and/or decide not to implement it. The team will very likely implement the software architecture as described, but may choose to improve upon it.

What does the process look like

There are many visualizations of scrum running around. Some are described in books, others in papers or blog posts. Most share some common elements. There is a product backlog that, through the magic of sprint planning, the team extracts a subset for the sprint. This becomes the sprint backlog. The illustrations then tend to show the various rhythms of Sprint as cycles (sprint cycles and daily cycles), ending with a demonstration and retrospective.

In order to illustrate and train a team on all elements, including the business analysis elements, we chose to be a bit more explicit about the steps PRIOR to sprint planning, including the processes of creating and improving the stories prior to the start of a sprint. (as above, click on the image to enlarge it).

Astute observers will notice that we added a step that we are calling “pre-sprint story review.” This is a meeting that occurs one week prior to the start of a sprint. It is called by the product owner and he or she invites “senior chickens” (architects, user experience leads, development and test leads, and any other “non-team” members that want a say in the sprint.

In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria. And here’s where the architects get to play. Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design.

(Note: assuming you are using a tool like Microsoft’s Team Foundation Server, that fully enables Scrum in multiple forms, this is a nearly trivial activity since a document can be easily linked to any story. Enough advertising.)

So is an architect a chicken or a pig? Answer: depends on what “layer” the architecture is at. The top two layers are chickens. The third layer, realization, is done by the team itself. The person on the team may or may not have the title of “designer”. (I’d prefer that they did not, but that’s just because I believe that ALL team members should be trained to fulfill that role. In reality, the skill may not be wide spread among team members). Therefore, the third layer is done by the pigs.

I hope this provides some insight into how a team can embed software architecture into their scrum cycles. As always, I’m interested in any feedback you may wish to share.

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!

Digital Disruption: Know the Fundamentals of Your Business

June 11, 2013 by Eric Meredith

Digital Disruption lesson #4: Know the fundamentals of your business. This is the 4th in a five part series about Digital Disruption.

Borders Booksellers operated for more than 40 years, growing from a local Michigan retailer to a national megastor…

How to build a Roadmap – Gap Analysis

June 11, 2013 by James Parnitzke

This post will discuss how to develop a robust gap analysis to identify any significant shortcomings between the current and desired end state. We use these findings to begin develop strategy alternatives (and related initiatives) to address what has been uncovered. The intent is to identify the difference (delta) from where we are to what we aspire to become. This exercise is critical to identify what needs to be accomplished.