EA Voices – Page 661 – Aggregated enterprise architecture wisdom

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.

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, …

Sometimes the small details do matter

June 11, 2013 by Tom Graves

It was the presence of the big-lens cameras that caught my eye, I guess… I’d just finished a great meetup in London yesterday with enterprise-architect Stuart Boardman, talking about the This-game, SCAN and requisite-variety, and their relation to Cloud and outsourcing.…

Ban the Word “Alignment” From Your Architecture

June 10, 2013 by Doug Newdick

Something about the typical language of enterprise architecture is starting to bug me. The overuse of the word “alignment”. When people are asked to describe what enterprise architecture is all about, they often answer with the phrase “it’s about the alignment of IT with business strategy”. But is that enough? Should it be something more? […]

NOTES – actors, agents and extras in the enterprise

June 10, 2013 by Tom Graves

If the enterprise is a story, who are the actors in that story? What are their drivers and needs? How do we model and manage the relationships between those actors in the story? (This is part of an overview and…

IBM’s Own IT Transformation Example

June 10, 2013 by Rajeev Bhardwaj

So what is the value of Enterprise Architecture, and how can it really guide transformation in an enterprise. How do you crisply attribute the value of good planning, and articulate it to others? (… as we read in my previous posts, Enterprise Archite…

IBM’s Own IT Transformation Example

June 10, 2013 by Rajeev Bhardwaj