Composable enterprise architecture as a starting point

Many government organisations are busy modernising their application landscape to respond to changes more quickly, in both politics and society. This revolves around functional decomposition: breaking large systems down into smaller parts. Then you can meet your organisation’s needs by using building blocks to create a working solution. This is called a composable enterprise architecture.

Built up

Designing and deploying this is much more than a technical matter. A composable enterprise architecture is built up of an architecture function, target operating model and target architecture, based on packaged business capabilities (PBC). A PBC is an autonomous collection of components, including applications and data. Think of it as the digital substance of the part of the broken-down value streams within an organisation. When determining how big or complex a PBC should be, you should ideally consult with the team responsible for that part of the value stream within the organisation. That way, you create an organisation where responsibilities are invested within teams that maintain the associated PBCs. Making a legal change to a grant, for example, can be quickly picked up by the grants team. And because PBCs are completely autonomous, you can make the change without depending on other PBCs.

Three stages

To build your composable enterprise architecture, Ordina breaks it down into three stages:

1. Set out. We start by exploring how agile you want your operations to be. We map out and draw up your data provision vision for you as a government organisation. Then, we draft the strategy for the supporting data stream and landscape, assessing the maturity of the architecture function and products.
   Together with your organisation, we look at agile working from different perspectives, such as: implementing new legislation and regulations, product innovation, sourcing strategies, adopting new technologies, restructures, mergers, or upscaling and downgrading production capacity. Designing an architecture function to guide and continuously manage the transformation is essential.

2. Set up. This second step is to establish the target operating models. We will determine how we will achieve the agility you need from the target architecture and application landscape. To prepare for this, we lay down criteria in terms of composability and work out how far your current data provision landscape already goes here. Once we have an outline of the business model, value chains and target architecture you want to achieve, we will test whether and how existing packaged business capability components fit into this target architecture. We also look at the quality and accessibility of the relevant data.
   We then look at that analysis to determine which specific steps are needed to migrate from your current situation to the desired one. This results in a transformation strategy. Aligning data provision and components with the business functions and users in the organisation through capability mapping is critical.

3. Set off. How we implement your transformation strategy depends on your specific situation. The strategy may include aspects such as rationalisation (reducing your data provision landscape complexity), legacy replacement and modernisation, migrating to other platforms such as the cloud, implementing standard software as a service (SaaS) functionality and custom software development. Application programming interfaces (APIs) play a vital role in making the application components work together well and easily.
   The transformation strategy is key to putting the frameworks in place to support the data strategy, lifecycle approach and agile production process. At this stage , it may also come to light that actions are needed to improve the performance of individuals in their roles.