5 November 2009

Insurance companies, banks and financial corporations are particularly challenged these days. Not only is the economical climate under pressure, organisations are faced with unprecedented complexity throughout their mission-critical business processes. Also, because customers are demanding more and more services, a dynamic organisation needs to cope with those increasingly changing requirements. Unfortunately, being dynamic often conflicts with the politically charged and hierarchical structure of a corporate enterprise.

A software factory should provide guidance on what off-the-shelf products can be used for what corporate duties

Dennis Doomen , Aviva Solutions Usually, business processes are realised by a heterogeneous landscape of systems, some already existing, some under construction, and adapting to changes also means adapting those systems. However many larger projects have been started with a big design upfront and are controlled by rigid project management methodologies, so that may not be easy at all. Adapting existing systems may appear less of a challenge, but that depends entirely on the level of quality at which those systems were originally designed. From years of experience in the IT market, we know that projects under stress tend to drop the quality standards a notch or two. Even worse, nobody can predict the future. So even though your architects may have designed a comprehensive system architecture and developed a promising proof-of-concept, you have no guarantee that those choices will work out later in the project.

What is really needed is an agile construction environment that welcomes change, promotes transparency throughout the entire system development lifecycle, and applies best practices that are known to encourage high-quality software. At Aviva Solutions, we typically refer to such an environment as a software factory. A software factory is not about constructing software through assembly lines. It is created by continuously harvesting frameworks, best practices, guidance, metrics and other experiences from completed projects. A typical factory includes guidance on architecture, coding standards, functional design, infrastructure, tools, and products.

One particular reason that many projects fail is that they assume that stakeholders know what they want from the start. In reality however, the most important revelations occur much later. Moreover, many initial assumptions change during the project. Team Foundation Server 2010, Microsoft’s integrated suite for managing and executing software projects can help with that. Out of the box, it supports an iterative software methodology that embraces change throughout the entire project, measures progress continuously and keeps management in control at all times. And in contrast to many similar products, it targets all disciplines involved in a project, including testers, requirement analysts, configuration managers, functional designers, and, obviously, the project managers.

Another aspect where a software factory helps out is by introducing best practices that strive for high-quality software. Automatic unit and integration tests, for instance, prevent regression problems. Evolutionary design ensures that the system does not contain any unnecessary complexity jeopardising maintenance. Pair programming increases productivity and quality but also ensures that the feedback cycle for potential functional issues is shortened significantly.

Not everything has to be built from scratch, so a software factory should provide guidance on what off-the-shelf products can be used for what corporate duties. For instance, orchestrating business processes over a variety of systems that use different protocols and technologies is typically something that BizTalk Server 2009 does best. And SQL Server 2008 Integration and Analysis Services can be used to extract and transform data from those systems into a central warehouse, which is exposed by Microsoft Office and Microsoft SharePoint through reporting and KPI dashboards.

Depending on the nature of the system and technology involved, many architectural choices have to be made. Fortunately, Microsoft’s Patterns & Practices team provides architectural guidance and advanced starter kits for different kinds of systems. These products consist of generic solutions that have to be customised to match the specific corporate requirements. But in order for successive projects to benefit from that, the specific choices and customisations have to be written down somewhere. Obviously, a software factory is the logical choice for that.

As said before, a software factory does not come in a box and requires a careful analysis of your organisation, preferably supported by an external coach and verified in a pilot project. But regardless of the nature and core business of your organisation, software factories should be an essential part of your IT strategy.

Dennis Doomen, principal consultant, Aviva Solutions

This article first appeared in the Autumn 2009 edition of Finance on Windows.

Add a comment