In the Architecture Office #6: Business, business, business…
Sep 9, 2014
Previously in the Architecture Practice: Chief architect Herbert Birchbranch (called Herb in the text) implemented a digital Kanban board as a mechanism to increase the throughput of work in his architecture office. Herb continues his journey to build a highly valuable and efficient architecture practise
Lack of B
As in many organizations the architecture practise was lacking business architecture and references to the business model. The focus and competence was clearly heavier on the technology side. Herb has realized that it’s not just to push a button and then suddenly business architecture is falling down from the sky. As with all architectural viewpoints there was a need to define what architecture makes sense and contributes to Quality. Competence and understanding of the area is also needed, as well as definitions and decisions about formats that are useful.
A new gun man comes to town
When Herb had been struggling with the issue of business architecture for a month, he suddenly received a mail from an un-known employee, James Berry. James wrote that he has been working in the Supply Chain organization for five years and now has been appointed as Business Architect for the Supply Chain area. He also wrote that he wanted to discuss business architecture. Just lovely, Herb thought. He had realized that he will need a counterpart on the business side to be able to develop and strengthen the business parts of the architecture. The IT oriented architects in his office couldn’t really contribute to this. Herb replied with a meeting invitation and that he was looking forward to the meeting.
The first meeting
The first meeting turned out very well. Both Herb and James had the same pragmatic view of architecture and architecture work. Herb presented his working models, and James replied that this is exactly what is missing today. Especially the early business dialogue which he meant was totally absent. The first discussion about business architecture was focused on processes. They both agreed that an open standard business model should be the foundation for the architecture product they decided to name Business Process Framework. James told Herb that they in the pre-study for new manufacturing system have used a standard model from Supply-Chain Council (SCC), Supply-chain operations reference-model (SCOR). Just perfect, Herb thought, if the business has decided about their model, just go for it. James, with his experience in the Supply Chain area was confident with the model, so they decided to build the business process framework based on SCOR.
The birth of a business oriented meta-model
James and Herb worked together during a period and agreed about two basic common architecture principles that will found their Business Technology ambition.
1. The business process reference model shall be block oriented!
The model will be more useful for different purposes and the blocks can be used to describe different business process scenarios. In the figure below the processes are described as blocks.
The blocks are divided and broken-down to levels. Supply Chain is level 0. Order, Engineer, Source, Make and Deliver are level 1. The blocks under each level 1 are level 2.
2. The process Level 2 is the joining level!
To create real business orientation, a process level has to be selected as the joining level. This level is then related to application areas, business objects, business drivers and other viewpoints that are valuable. Herb and James decided to start with level 2.
Herb made a simple meta-model of the different key architecture pieces and how they fit together. All based on the dialogue about value he and James has had. He thought that some of his architects may question it and say that it is too simple and useless. Does it have to be more than this, to start with, he asked himself.
The meta-model in short
On process level 2, James has got business drivers defined by the business, called Business Capabilities.
The scope of a logical Business Application Area, like CRM, Warehouse Management and Finance, is defined by the set of level 2 processes it is aimed to support.
A Business Application Area needs Technology to be able to operate, and it may need Infrastructure Application Area platforms like Integration, Analysis and Workflow to fulfil its objectives.
The work with the information level will further elaborated. The first step is to define and relate the main business objects to level 2 processes and to define the main information flows in and out.
Conclusions
To relate architecture to business is very important in today’s movement towards Business Technology, though most many organizations still are lacking useful business architecture.
Success with business architecture requires people on the business side that understands architecture and what really is needed.
The most important starting point is the business process reference model, which should be used as the connecting object for other architectural viewpoints.
To save time and heritage best practice, the best is to start with an open standard model and adapt it to the specific situation and need of your organization.
Create a simple meta-model of the architecture objects to start with. Extend it when and if needed.
Next: How to create a business oriented architecture with a pragmatic touch…