Confusing Business

So, in my previous blogs I noted the need for a standardized language so that we can all speak – IT and the Business that is.  This brings up the old saying: “One dictionary breed understanding, two or more breed confusion”.  When it comes to Business Architecture – the definition of the business (who, what, where, when, etc.), this is one of the least understood areas in Information Technology (my opinion).  We in IT struggle with understanding the business – or is it the business that struggles with explaining themselves (and their needs or requirements) to IT.  Either way, there is a gap or disconnect that we have to bridge.

In the development of my very first Services Based Architecture (SOA) in 1995-6, the team I was working with conquered this challenge by inventing a graphical language to define the business requirements graphically.  We used circles and arrows, something that was easily understood by all the business people we worked with.  Behind the scenes, we were error checking and validating that there were no missing links, open connectors, etc.  The reason it worked, I believe, was that it was very simple for the business to grasp and take ownership of. From this, we were able to decompose the business into granular services and wholla – the first SOA was built.  This system is still in use today!

In the previous blog I noted that ‘The Zachman Framework’ works – and it truly does!  Although, my only critique would be that some of his diagrams (like swim-lanes) are not highly expressive and business people sometimes have their eyes glass over when looking at it.  It does what is needed however – creating a common language between the business and IT and John was truly a pioneer in this space.  It is not designed for the development of Services Based Architectures since it does not include Actors, Artifacts and Processes on one diagram, but you can easily add this by separating the How into ‘Processes’ and ‘Functions’ or by adding a new diagram to his set.

Recently, I came across a very expressive language that was developed in South Africa by a gentleman by the name of Bert Engelbrecht.  He had spent years developing this very easy to understand graphical language (pictures that were truly worth a thousand words) that had a background in mathematical theory and engineering.   He used Microsoft’s Visio and added a repository to the back end to capture metadata and his tool is very in-expensive (I think about a thousand dollars) and very powerful.  You can look into his language at: www.discon.co.za 

I am sure that more tools will come out to assist in this area, but my old boss once said: ‘A fool with a tool is still a fool!’ and he was so right.  You can do this with crayons’ as long as both teams (business and IT) understand the drawings.

Anther thing that drawings do is graphically envision the subject areas and other distinctions that will be used in iterative development.    Since very few organizations try to build enterprise SBA / SOA’s, the drawings allow us to circle the iteration and then place stubs where the future iteration will require input.

A common language can also be enhanced or facilitated with Governance – something required when building an SOA and working with data and will be the focus of my next blog.