Business architecture seems to move from the pointless to the absurd. Why do organisations spend so much time and money on documenting business processes and requirements only to see nearly all IT system deployments run over time and cost?
Can It Ever Be Useful?
Technically, by modelling business processes the business analyst (BA) should be able to derive the functional requirements of a system – largely by analysing “events”. Here’s how it should happen:
- The BA derives the Business Process Use Cases from the analysis of process documents.
- The BA then works with the business to devise ‘realisations’ of these use cases.
- The realisations are then analysed for System Use Cases.
- The system analyst (SA) then works with the tech teams to design system realisations which instantiate the system use cases.
- Then the programmers work to code all this so that the new system does exactly what the users wanted, i.e. business functionality.
So Why Does It Never Work?
The litany of well documented IT project failures highlight the fact that this process usually does not work. Although the process is clearly broken it is not fundamentally flawed. Firstly, requirements structures are over-simplified and their levels of abstraction are confused. This means that the link between most business modelling and business use case development is intuitive and a leap of faith.
The process of requirements development is well documented in the Rational Unified Process (RUP) and well supported by sysML, UML and Business Motivation Modelling (BMM). It is usually through a lack of BMM, however, that the process falls down. Not only does the process not work it also serves to hard-wire bad culture into the business. By designing software from poor requirements the business not only increases the cost of future change (approximately equal to x100) but it also ends up coding bad culture – the very culture/processes they wanted to steer away from by designing new software.
So What Is The Value Of BPM?
Apart from the sheer cost saving ability of a sleek requirements process, Business Process Modelling has great value in automating processes. BPMN models can be exported to BPEL and executed as computer processes. This gives huge flexibility in orchestrating complex process and workflows between machines.
Designing Directly from the Value Chain
The real power of good business modelling is when it gets ahead of the design curve and starts developing business architecture directly from the Value Chain. By analysing the hot-spots in the finances and then determining whether they are valuable-spots within the Value Chain, business architects can begin to develop or rationalise designs before they become pet projects. This is not done already, largely, because accounting standards mean that (a) costs are not coded according to a business’ Value Chain, and (b) virtually no business has a well documented Value Chain to start with. However, it is a valuable exercise to understand the correlations and dependencies between what a business spends money on and how it earns revenue. Who better to do this than the business analyst/architect?