Enterprise Architecture

  by Tim Coote | 28 Aug 2007 | Permalink | Everything Else, Featured, IT Management, Project Management, Software, Software Business Models, Software Engineering, Teamwork, Web 2.0

Back in the early 90’s I was a consultant in a large systems integrator. Moore’s law and de facto and de jure standardisations were breaking proprietary systems’ stranglehold on customers, driving the ambitions of organsations to increase the scope of their IT across the value chain and to get economies of scale of technology ownership, while increasing the end-to-end automation of their enterprises to reduce business operational costs.

Early attempts failed to achieve the vision because it’s really hard to stitch together IT systems that weren’t intended to be stitched together: simple project management, which implied that the project manager understood the impact of technical decisions, no longer achieved what the customer wanted. So we invented the role of Enterprise Architect and moved towards the model used by real architects on large construction projects, where the project manager supports the architect, rather than the other way around.

The skills of the enterprise and technical architecture roles that we built enabled our customers to capture and act on previously implicit assumptions about what the business was trying to achieve, both avoiding pitfalls and grasping opportunities.

The usual pitfalls and examples included:

• ‘unexpected scope creep’, invalidating an existing technical architecture based on naive assumptions about future use of a solution: although the initial requirements for an emergency response system showed that a simple hardware failover model would work, close to implementation, it emerged that a grown up transactional model for the application was really required and expensively retrofitted.
• inadequate testing of the technical / application architecture before spending all of the budget building the functionality: 20MM GBP spent on a trading system that was never going to work.
• inadequate assessment of packages and frameworks (a special issue in Web 1.0): estimates used in planning were for 90% of the development effort would be taken out by a web content management system. Unfortunately, when new key stakeholders were identified and all usecases elaborated, the initial saving dropped to 40% and the extra costs of conforming to the product’s architecture swallowed all of that saving and then some.
• missing overlap analysis – although consultants were familiar with gap analysis for business process and simple IT implementation, the bigger challenge in larger systems is in reconciling the incompatible assumptions of existing components. This missing work from initial estimates caused many projects to be re-evaluated, especially for assumptions around data meaning and timing assumptions.
• weak governance in many forms: programme sponsors who got themselves promoted before the impact of a solution could be measured (and the ‘surprise’ challenges of the project that become visible afterwards); inadequate enforcement of design standards such as a technical architecture aimed at providing a customer centric view being ignored by some projects, leaving IT systems that can only deliver a product centric view.
• automation of errors: if you automate two business processes that used to have humans to drive them, you’ve got to get the error rates very low and it is very rare that existing applications supporting the current processes are up to the task. If you fail to drive down the error rates, a system failure can generate a run-away effect, where business errors are created so fast that there are not enough people to fix them – especially if you’ve been aggressve in making savings and have fewer staff who understand the business processes and how they should work.

The opportunities grasped included:

• effective exploitation of deregulated industries through automated, scalable forecasting and error handling that enabled arbitraging of the buy and sell side of contracts
• better investment decisions for web and other automated services: avoiding overspend on non-existent opportunities and more rapid deployment in real opportunities
• realisation of the identified benefits of simplified systems integration.

So, why is all of this relevant to me today? Because I’m seeing some of the same mistakes and opportunities in the enterprise systems management space that I saw in the enterprise application space ten years ago…