Are you an architect? If you are – what is your goal? All architects, whether they design buildings, cities, landscape, or enterprises, must work towards a goal.
Business architects may aim for the same goals and follow strategies that apply to the enterprise. Most business architects probably do so. Yes, we all want to contribute to the success of the enterprise. But there is a twist to this subject. And for us, it is a major one.
Accelerated rate of change
We know that businesses and societies change at an accelerating rate. Even if we know this for sure, we will still be surprised by changes that come next month or next year. But we do not know what exactly will happen or when. But we know changes will come. They will impact our business, and of course they will impact our architecture. And when this happens, we will normally not be prepared.
Developers have seen the need for a capability to swiftly adjust to new requirements. Methods of agile and DevOps are initiatives in the right direction. But what do architects do to swiftly adjust?
If we continue to design the architecture according to the current goals and strategies, we will always lag behind have to redesign the architecture every time to meet new requirements. That is normal. But is it ok? Can we do better?
No, that is not ok! And yes, we can certainly do better!
Agile for the unknown
While developers care for the current change initiative, or project, we as architects must in addition also care for the whole enterprise. The difference is seen in the expressions “agile development” and “agile business”.
Our suggestion is that the architecture must be able to prepare for the unknown. Therefore, we will design the agile business. If we manage to design the agile business, then we can handle sudden unforeseen changes with speed. But how do we design an agile business? How do we prepare for the unknown?
Hard to change
Our assertion builds upon an understanding that changes, for most cases, are hard to accomplish. This is especially the case for medium sized to large organisations. Let us list the most common reasons:
- We have way more systems (or applications) than needed (application redundancy)
- Each application is allowed to own its data, which leads to data redundancy
- Application integration adds complexity
Problems like these are solved by introduction of new tools and technologies. This may help in the first wave of trouble, but it is counterproductive in the long run. Cost and risk get inevitably higher and higher. In his book Software Wasteland, Dave McComb has documented the history and current state.
And the message is clear: More of the same does not bring you anywhere else. We need to take another route. It is not about technology. It is not about tools. And it is not about the art of programming.
It boils down to data. Data as a common resource. And applications that will no longer be allowed to own the firm’s data.
The change is so severe that we must say it is a change in architecture. And it is a change in mindset. The change is larger than one project (or change initiative) can accomplish alone. It changes the way we buy systems (applications) and how we cooperate with vendors. And it changes the way architects and developers work together.
The changes are severe for all enterprises. For large companies it will be a matter of survival. Start-ups and smaller companies that break with old habits and go for a new architecture, will experience a far better ability to change, and they will have substantially lower costs and risks. In the long run economies will force the large companies to change.
Yes, the changes have to do with application architecture. But a foundation for this new design is in the business architecture, especially in the information architecture. Firms must become data-centric.
In our next post we will tell you how. Continued in “Prepare for the unknown II“.
Leave A Comment