Companies are currently in the middle of a major digital transformation. Being able to quickly respond to new customer needs and expectations is crucial. Consequently, project teams are being organised differently. For example, more and more SCRUM teams are being put together to provide software more agilely. However, a question I’ve been asked by customers repeatedly concerns the place that architecture must be given within this story. My opinion is that a minimum of architecture is always necessary. Just enough, just in time. In this blog post, I want to illustrate a technique, based on a previous project, that lets you gain a helicopter view with a minimum amount of enterprise architecture, which is something that is unarguably adding value for a company that is going through a complex transformation.
One of my most recent projects entailed work for a financial player that was thoroughly transforming its mortgage loan application process. The number of business stakeholders, who each had their own needs, was high. Moreover, the project was strategically important. There was a strong need from various angles for a clear view of the project’s impact. As a business architect, I worked on meeting these needs together with the colleagues.
We implemented an interesting conceptual framework that I would like to share with you here. It describes what the various aspects of a company are:
You can also apply this framework at different levels: for the entire company, but also for specific parts of the company (i.e. business capabilities).
We applied the above-mentioned framework to our customer’s Loan Origination Management business capability. For illustration: the ‘customer’ is the consumer who applies for a home loan, the ‘process’ is the application itself (from the simulation to the credit scoring, signing the contract, etc., the ‘people’ are, among others, the bank agents who provide the customer with recommendations, the ‘knowledge’ concerns, among others, the rules that are applied to assess the customer’s credit score, and you can continue going over the rest of the aspects in this way.
The result of our exercise was a one-slide presentation (‘one-slider’) that clearly showed the impact of the transformation on each of these dimensions (aspects). This allowed the various stakeholders to clearly see the manner in which their department was involved and how this was situated within the greater whole so that they could make decisions at the right level.
Naturally, the enterprise architecture work usually does not stop here, and that was no different here at the bank. Each of the aspects mentioned can be further discussed to support the complex transformation in this way. However, it’s best to focus on aspects where the need is the highest (just enough). Don’t start adding too much detail too early: start with helicopter views and only go deeper when this is required to achieve the transformation (just in time). For example, at the ‘process’ level, we started with an incredibly simple high-level process for a loan request consisting of five blocks. This allowed us to structure the requirements analysis. It is only when the detailed functional analysis started that we began to explore the five blocks in more depth, going one level deeper. We held several workshops at the ‘Value’ level to sharpen the value proposition. To clarify the ‘Tools’ aspect, a ‘use case diagram’ provided an overview of which functionalities were in scope: the perfect stepping stone to more detailed analysis of the IT impact.
Would you like to try it yourself? How would you set up a one-slider? Let us know in the comments.