You may have noticed in the Blogs from my colleagues, and me that as we are working through building a new generation of architecturally based ‘SOA’ style solutions we have started to come up with several reoccurring themes. The further we move towards really starting to design and implement new processes to take advantage of some of the core business values in the new technology the more we have started to realise the persistent problem that we have started to refer to as ‘Business Architecture’.

As you can read about this in more detail in some of the other Blogs I won’t elaborate, just say simply the problem of expressing Business process seems to be very difficult. But is this so? We have had some forms of ‘work flow’ management for a good view years and there are even notations for defining the stages in a process, take a look at the symbols in PowerPoint.
It was only after looking at the subject for a while that we finally thought we saw the reason, and the inherent trap in thinking that we believe it induces. The answer is that we still think in terms of paper, content capture, and filing cabinets, without even realising it! We even deliberately created most of our applications to be this way. We don’t actually think process at all, we instinctively think data, and about transactional outcomes which when we move to collaborative interactions is in most cases the wrong approach. To understand this it helps to understand why we do this, and what we should change in our thinking.
Let’s start from the beginning, and the idea that a business could only develop around a physical location called premises with administration in a room called the office, and in the corner of that office there was a filing cabinet. Pretty simple in the beginning in terms of the headings under which to file things, probably C for Customers, and S for Suppliers, was good enough! Pretty soon the growing company found it needed more and more filling cabinets and the difficult of finding anything in the filling cabinets became pressing leading to a deliberate move to split up the single continuous business process into separate sub processes, based on the headings in the filing cabinet.
As time passed and our successful company grew this sub processes became fully functional departments with specialities that enabled them to capture, index, file and find again those vital pieces of paper. Jump forward again, to early department computing with the mini computer generation and the computerisation of these departments, did anyone recheck the process? No, the success of early applications was to duplicate the existing process, and to reproduce the filing cabinet in the form of computer data. It’s no accident that the eighties saw databases as the hot technology of its time; it was the most crucial element!
Jump forward again and see the separated silos of departmental computing built around data being integrated by ERP. Having created the problem we needed ERP to help solve it. But was this by enterprise business process, or by data at an enterprise level, albeit with departmental level best practice improvement? Well we know the answer to that and the next generation of ERP does really start to address putting business process at the centre of its capabilities, but are we thinking clearly enough about how to use it?
Add the whole technology shift to SOA making for self describing interfaces to dynamically improve and extend process, plus the impact of Web 2.0, almost a technology that leaves no recognisable data behind it in many interactions, and our data centric view of process looks
Suspect. Bit like applying PCs in the early days, it’s a small cheap departmental computer, right? No, completely wrong, we had to learn why the hard way, and we are still learning now as the SOA + Web 2.0 wave changes the game again.
Let’s just think about a purchasing manager in a manufacturing enterprise. There is a clear benefit from placing the person with the management of the production line and integrating their operations. Equally, there is a good case for putting them with the largest supplier to coordinate through integration the flow of goods, pricing etc. What’s the case for isolating them from both and putting them in an office with other purchasing managers? Is it access to information, expert advice, information, etc? Certainly shouldn’t be as any of these things are no longer dependant on physical location these days.
If business and technology, (techno-business?), are completely intertwined and have come to be the same thing then its finally time to throw out the filling cabinet mentality for once and for all. We need to be able to define, correlate, and initiate process by its interaction goals, and not by its transaction data models, that’s the clear message that we all have come to understand. Hence our interest in what we are calling ‘Business Architecture’ as the method to state and notate these objectives.