The perceived lack of business value of visual models

Why is the apparent business value not found in visual modeling?

Maybe it varies between countries and cultures, but it appears to me from my personal viewpoint, experience and in reading forums that many people, the vast majority, do not seem to find much if any business value in Enterprise Architecture visual models done in formal notations such as Archimate, BPMN, UML and the like, be that for Software Development projects or proper Enterprise Architecture. Besides the usual explanation of a picture paints a 1000 words and is therefore valuable, it is difficult to understand why this is the case? I have some ideas why this is the case but I’d be interested to hear other peoples views on this.

I am also specifically more interested in True “Enterprise” centric Enterprise Architecture, not the dumbed-down IT centric view of a sub-set of EA that is all pervasive at the moment. I am less concerned about the detailed software development models than the enterprise architecture level models, however there is an intersection between what data and applications are implemented in the organisation and the proejcts that implement them.

My ideas as to why visual models have lost favour

I am exploring this concept and have a few ideas as to why this change has happened and why I think it might still change back again somewhat, until we reach a happy medium somewhere in the middle.

Waterfall software development moved to a more agile and adaptive way of working.

• Visual modeling was seen as a blocker to making quick progress in development projects and therefore largely thrown out, with the exception of a few quick whiteboard models as a means to an end.
• In the 1990’s – 1998’s when case tools were all the rage, people found value in visual models, for a period of time.
• Then later too with Grady Booch & Rumbaugh, et al, in the early 2000’s with the Unified Process, RUP and UML (with its Use Cases, Class diagrams, etc.).
• But since then as the more adaptive software development methods have come into play, some of the benefits it seems, like the baby have been thrown out with the bathwater. I understand why, but I have a potential solution to that.

The internet with eCommerce and Y2K came along and disrupted the way IT departments were beginning to work.

• I know, I tried to introduce Enterprise Architecture concepts of Vision, mission, goals, objectives, strategy and capability models in a dot.com in 1999/2001 and failed miserably because nobody had time for such thinking, it was all Do or Die, Do Do Do, get to market, we are too immature to be doing all that big company stuff, Just do it!
• Likewise Enterprise Architecture seemed to also be put on the back-burner between 1998 and 2007 for the same disruptive reasons of the internet coming of age.
• This distracted everyone for a decade until we all got used to www….com’s and integrated this all into the traditional IT.

Finally, because when most people look at a visual model, all they see it as a stand-alone disconnected piece of information, not as a part of a larger whole, which if it came out of a joined up logically connected repository with a suitable meta-model behind it might not be so disconnected and stand-alone.

• People are so used to seeing Visio & PowerPoint diagrams, that there is no concept of and underlying database of information that joins all these concepts together. Many have never experienced some of the tooling that is possible, and if they are shown it, it simply does resonate very well.
• Ironic because the CxO’s understand ERP, and realise we cannot run large organisations on Financial spreadsheets anymore, but are happy to run the IT department and more particularly Architecture on spreadsheets, PowerPoints or collections of files in a CMS like SharePoint.

How big upfront design concepts and modeling got stopped

The logic of why Big upfront design got thrown out I do not question, mainly because by not delivering working software which is the primary goal of any delivery project, makes sense. However what we are now left with is years of “working” software (even the “working” aspects are sometimes questionable) without any reasonable documentation or architecture to explain what we have.  Sure sometimes people write comments in the code, and other times fill out the wiki, but it never seems to be overly reliable or up to date, or is that just the case where I’ve worked?

But of more concern to me is the lack of backing business documentation about the original business and product architecture, which is even more of an issue when it comes to making changes to the original systems. So now when change comes, we do not have a baseline to work from, nor do we have too much of a systems architecture outside of the architects heads.

So when we have to make enhancements, there is very little context for people who are new on the team, or who did not live through the original project experience. Not only from documentation of what architecture exists currently that needs to be enhanced, but also the architecture of the explicit deltas of what we need to change are difficult to ascertain. This is where the business value of good models begin to make more sense. If we had some of this in place, then the changes would be quicker and easier to implement, and avoid the introduction of new changes that could break the original intention of the systems functionality.

So how do we regain the business value?

The problem then is if we do not build these models during the development, when would be build these models? if we leave it too late, people have moved on and also it takes time to gather this valuable information and be accurate. Answer: We need some Cartographers to chart our systems, while the Scouts are out doing the development and transformation changes, just like in the old days.

An analogy between visual models and the great maritime navigators of old using cartographers & scouts

Taking directly out of a AEA forum discussion Roderick Lim Banda shared this great analogy: “The one analogy I developed and continually use when engaging in AEA or EA as a whole is that of a navigator. In the days when the world was chartered by sea and reliant on navigators to both map and guide explorers, one could think of navigation in two distinct forms. There was a cartographer who would map and observe and guide Captains and there was the scout that would lead inland explorations. The latter would be part of the journey much like the “embedded journalists” of CNN that changed the nature of television news. But the trade off decisions made by the scout were critical and required that “quick of your feet” type of agility using knowledge and experience.

Today, many EA practitioners find they have to transition between Cartographer-Scout Navigation and this is why AEA matters if EA is to matter at all. As time passes, there is less to map but the journey and trade-offs are constant. And with scouts, all skills (human and technical) remain relevant – upon which survival against risk is dependent.”

Separation of Tactical and Strategic work during software development / EA development

So using the above analogy, there ought to be a separation of concerns and roles to optimise both delivery on its own delivery lifecycle and strategy on its own business-as-usual cycle as shown in the archimate diagram below. This means that we still get to gather the strategic information about the company, as well as not hold up development and delivery by causing extra modeling work to be done by the team. The Cartographer should do that part at any convenient point and do it regularly so that it is kept reasonably up to date.

I am only talking about information harvesting from Projects to the EA central repository here, not about the knowledge flowing in the other direction (from EA repository to Project), which is all about Governance and optimising Project level designs in the best interest and context of the organisation. That is a separate and relevant discussion not impacted by this concept, in fact it enhances this aspect because there is more collaboration and a deeper understanding of the facts between the parties.

So how does all this enhance the business value of visual models?

Well, because it means that the information is gathered and captured into a central EA repository, consistently and therefore kept current and relevant for all elements in the enterprise portfolio.

Here we assume the use of a proper EA tool not a spreadsheet or visio diagram, unless it has an underlying central repository that is keep up-to-date. This means that any diagram is captured into or derived from the basis of a queryable set of related underlying information. This then gives the ability to do impact analysis, highlight traceability, keep records of architectural information (just like an ERP system does for the other parts of the business) – both in diagrammatic format as well as in textual database formats.

Finally some interesting information

As I was finishing this blog, I got a tweet about the visual impact in marketing, which shows some interesting facts about how people perceive graphics over text. Why then is this not the case for models in companies? Or is its day yet to come?

http://blog.bufferapp.com/infographics-visual-content-marketing

Better still this blog should have been a Video Comic based presentation. Maybe I’ll find the time to do that instead. 🙂

 

References

http://en.wikipedia.org/wiki/List_of_cartographers

http://en.wikipedia.org/wiki/List_of_maritime_explorers

http://en.wikipedia.org/wiki/James_Cook