All too often, tremendous effort is applied to resolving the symptoms that result from perceived and actual problems. The effect is short term solutions, which often produce counter-intuitive side effects. My view is that - not unlike traditional architectural problems, where the effects of bad design are often separated in time and space from the causes - only an understanding of the underlying business structures can lead to valid, long term solutions. This view is what differentiates business architecture from quick fixes.
Business architectures - just like any other structure - need to be designed. The design process needs a clear definition of requirements to produce sensible results. Once these have been gathered, along with the metrics neccessary to measure the subsequent implementation success, a variety of options can be developed, analysed and evaluated. The preferred solution - maybe because it meets the requirements better, or it is easier / more cost effective to implement - is then designed in detail. Detailed planning facilitates better and faster implementation, as most issues have been identified "on paper" and suitable options or workarounds developed. The process is not unlike that followed by an architect designing a house and supervising its construction - or when was the last time you watched an architect "design" a building by having a team of bricklayers build a wall here and then one there to "see if it works"?
The tools and processes I use are those I learnt while studying architecture - blank pieces of paper, a soft pencil and an eraser. OK, I've since added whiteboards and drawing software to my repertoire, but the idea is the same and the aim is to develop lots of workable and not-so-workable ideas. The pictures I draw look different that those I drew as a student, although Function Hierarchies, Data Model and Process Flows have lots of similarity with the so-called bubble diagrams that are the start of every building design process.
[I have a view, that all diagrams can be abstracted to nodes and the connections between them and that it's basically the naming of the model - this is an E-R model, or an Org Chart - that determines how the model detail needs to be defined - the lines in an E-R diagram have different significance than those in an Org Chart. These ideas will be documented here eventually.]
In the world of architecture, models have a role to play in understanding issues and getting the detail right.The models in business architecture use different tools - maybe Excel, maybe simulation software - but the reasoning is the same. Models allow for a quicker and more cost effective evaluation of the famous "what if?" question and always serve to enhance understanding of a problem area. Of particular interest in this context, is the area of System Dynamics, which helps understand how the detail of complex (business) systems interact and vary over time.
But the best design and the best understanding of a problem is of little value on its own. The building, as it were, must be built, the business architecture must be realised. In the IT world we talk about implementation, in process projects we talk of (re-) engineering. Again we need to understand what it is we are trying to achieve (requirements), and how we will recognise success (metrics). Then we must analyse the route to completion and the steps involved in getting there. Along the way, we have to manage the golden triangle of time, costs and quality. Basically we have a problem that needs to be resolved - the process of resolution is commonly known as Project Management, which is something I've been doing since I first climbed up a scaffolding in 1982!.
I hope you enjoy this web site and that you find some or all of the content useful. If you have comments or questions, please feel free to Quick-Mail me.