Enterprise Architecture and Application Portfolio Management

mcronin Aug 19, 2016 Architecture

Agile & DevOps are seen as the keys to the doorway for successful transformation in all kinds of organizations. Indeed in engineering product companies (ie Google, Amazon, Facebook, Twitter etc) and highly architected organisations (e-commerce players such as Gilt) it is clear to see how a product approach works and what the roles of Agile and DevOps are there.

Now global financial and insurance organisations are looking to follow.

There is however a key difference between organisations like Facebook, Amazon, Gilt, NotOnTheHighStreet, Twitter and large global insurers or international banks. The former group all have one (or only a few) product(s). The architecture of the organization both technically and organisationally pivot around that single product.

Financial institutions typically have many business products and offerings. While there can be a 1:1 mapping, financial institutions are usually not technically organised directly around those business product offerings. They are also typically not organisationally built around those products. Organisationally, these institutions are built around markets - business units - and global presence.

So yes, financial institutions should join the Agile/DevOps rave, but before doing so need to address how they are structured both technically and organisationally. They need to start moving their organization to pivot around product. This means first asking the question - what are our key products?

Many large organisations have program management offices, owners of portfolios & programs. These groups govern the delivery of programs for the organisation. They have an oversight of the portfolio for the coming years (typically a 2 to 3 year road map) and would typically own the budget and budget allocation for these activities.

These organisations also have Enterprise Architecture teams. While enterprise architects do get involved in program delivery, an enterprise architect typically has an overview of the organisations target production landscapes. These enterprise architecture teams should have a 3 to 5 year roadmap for the organisation.

Regardless of delivery and build methodologies, between the enterprise architecture team and program management office team there should be a global overview of business requirements, delivery vehicles (projects and programs) and target physical landscapes for the organization.

In your Organisation; before trying to adopt DevOps - or even Scrum, before evaluating at cool tooling or putting developers on seats, bring your EA and program management office teams together.

Interestingly both the Agile Manifesto and DevOps strongly encourage teams to sit in the same room to enable close collaboration (of course this isn't always possible). In our large financial institutions the first teams “to get a room” should be the EA and PMO teams. As well as sharing the same physical space they should also strive to share the same “tooling space”. For example a tool like JIRA to track topics. The work outputs of these 2 teams should already have many common touch points realising the organisation’s business goals. By sharing the same space, tooling and communicating regularly they can identify commonalities and address potential organisational challenges faster. Once collocated, in the same technical and virtual space, the 2 groups should take key commonalities between the 2 roadmaps and begin to identify products rather than projects. For example a large global claims program could be broken down into a series of products (Claims, Policy, Billing). From the products try to start identifying features (telematics, billing analytics, first notification of loss etc.). This is all content that both teams are aware of but until this point being organised and managed differently (PMO team using projects, EA team using systems, pace layering). Both teams now should have a common output organised into products and features. Having identified products, organisational silos can be removed and teams can be organised around those products. Having identified the features of those products - themes, epics and stories can be more easily identified and a mature product backlog rapidly created.

It is also easy to see what products could become DevOps products and be continuously evolved. It is also easier to see what could be shared in the organization (cloud, tooling, business services).

So before the Scrum room, before the DevOps and Serverless rooms, before modular and microservices - get your EAs and PMOs to sit together and a bit like the pokemon hunters, find the products and features of your organisation!

Previous Post Next Post