~ By Ronald Schmelzer
One of the most challenging aspects of Enterprise Architecture (EA), and Service-Oriented Architecture (SOA) in particular, is that rather than address a discrete problem or set of problems in the enterprise, it attempts to address a range of interconnected and perplexing issues that have long troubled IT. Specifically, SOA approaches to EA address long-term issues of integration in environments of continued heterogeneity, application development in the face of continuous change, governance, management, and quality in environments of continuous complexity, increasing reuse and reducing redundancy across multiple IT initiatives, and organisational and methodology approaches that favour iteration over monolithic, waterfall-style approaches to development.
While none of these challenges are new, and in fact, many architects have a number of tools, techniques, and approaches at their disposal to address those issues, EA attempts to address them in a holistic manner, providing a consistent approach to use in the face of continued business and technological change. One of the biggest impacts of this holistic approach to IT management is that discrete IT project management is rapidly going by the wayside. This doesn't signal the death of IT project management, but it does suggest that evolving approaches to EA require changes not just in technology and application development approach, but also changes in the way in which we manage the organisation's overall evolution given that it will become harder to distinguish between development of individual IT projects and advancement of individual IT resources.
Most corporate IT environments have significant complexity. Even if the set of systems and applications are small in number, their interconnections, customisations, and dependencies quickly evolve into a morass of complexity referred to as the "IT rat's nest". Into this environment of IT complexity, the business continues to impose their requirements and changes, resulting in the creation of yet more IT resources, interconnections, customisations, and dependencies. This web of complexity quickly becomes so thick that any change to one part of the environment, say a data schema changes, has ripple effects throughout the whole of the organisation. Like a game of pick-up-sticks, nothing can move without moving the whole pile.
Yet, most companies still do traditional IT project management in which the requirements are defined and budgets set as if that IT project has no interaction with any of the other IT projects and resources that already exist in the company. In an environment where the web of complexity exists, the notion that you can pick up an "IT stick" without disturbing the rest of the pile makes no sense. One of the prime reasons why many IT projects go over time and budget is because the requirements that seemed simple turn out to be more difficult than anticipated. Some of the difficulty comes from imprecise definition of requirements, but the majority of the challenge comes from realising how one requirement impacts the system as it already exists. "The Devil's in the details", as is often said with IT project management, and the Devil is complexity.
Companies that have no plans to do any sort of heterogeneous application development or composition, or who have the time and budget they need to deal with constantly expanding projects in the face of continuously expanding complexity can afford to do discrete IT project management. But for the rest of us, any movement we make to try to bring the organisation's systems together into a predictable, composable, governed, loosely-coupled, and potentially reusable set of assets, or in other words, to apply any real Enterprise Architecture, will require that we stop doing IT project management in a discrete fashion and treat IT as a continuously evolving asset.
Vendors, consultants, and end-users alike over-use and abuse the "Business-IT alignment" refrain without truly understanding what it takes to bring IT into alignment with the rest of the business. Simply facilitating the business requirements to IT implementation generation process is not enough to really turn IT into an asset rather than a cost centre. Rather, what's required is shifting the responsibility for the application of IT to the business and changing the organisational and funding model to reflect the role that IT has as part of the business, rather than as something that needs to be in alignment with it.
As a case in point, like IT, human resources (HR) and finance are two other assets of the business. A long time ago, companies realised that it made little sense to let each function of the business manage its own finances and human resources. Why should each business group do its own hiring, benefits administration, and office allocation when that role can be centralised for the purpose of efficiency and optimisation? So too with finance - why should each role in the business manage its own cash flow, investment, and company-level reporting when it can be centralised for the benefit of the company as a whole.
The key insight here is not one of centralisation, since many will claim that IT is also centralised as such. The requirement is one of separation of responsibilities. The HR and finance organisations are not in charge of figuring out how the people and money resources are used. They are simply in charge of managing them for the benefit of the company. It is up to each individual line of business and role to determine how to use the people and money available to it. So too with IT. The IT organisation needs to move away from building applications on behalf of the business to providing services that the lines of business can use for their purposes. If we take this perspective of IT as a resource and IT management as management of the IT assets, then we can no longer think of IT project management in the same way.
In the game of IT pick-up-sticks, IT manages and creates the sticks such that when the business picks one up, the model is in place to deal with the iterative changes required. Note the nuance: business picks up the sticks, IT manages them. Say goodbye to discrete IT project management and hello to IT portfolio management.
A full discussion of IT portfolio management would require more room than we have here in this ZapFlash, but the core concept is that the IT organisation attempts to manage a set of continuously changing resources such that when a new requirement comes in, it doesn't automatically spawn off a new development project. Rather, the IT organisation leverages its growing "catalogue" of IT services to meet the continuous needs of the business. Any requirement that is not fulfilled by the existing catalogue will require either reconfiguration of existing assets, modification of existing assets, or new asset creation, in that preferable order. But even in the case of new asset creation, the project is the asset creation, not a project aligned with the specific business problem.
The Wikipedia entry on IT Portfolio Management further defines it as such, "the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities… The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios."
Many of you readers might be scratching your heads right now and wondering, "aren't we already doing this?" Or perhaps you are saying, "I don't get how this is different than discrete IT project management." If you are wondering that, then you haven't yet experienced IT portfolio management, since to do IT portfolio management requires, in most cases, a fundamental change to the lines of IT control and budgeting. To attempt to do IT portfolio management in an environment where the funds are being allocated to projects is a recipe for disaster.
Indeed, changing the method of IT funding is one of the fundamental requirements for a move to a portfolio-centric style of IT management. In an environment where any new business requirement might require changes throughout the organisation, it makes no sense to feed IT on a per-project basis. Rather, in an environment of continuous change, the IT organisation needs to be provided a continuous, and steady, budget that provides for continuous changes on an iterative model. Each iteration will introduce new assets, versioned assets, and configurations of assets to meet the current set of business requirements. The IT organisation then seeks to optimise its portfolio by minimising the time between iterations, the amount of changes needed in each iteration, the total number of assets under management, and increasing the visibility the rest of the business has of the IT assets under management. In an environment of continuous change, IT needs a continuous funding model to enable to continuous value to the business.
At the highest level of simplicity, all businesses need to manage only four resources in order to maintain success: money, people, technology, and supplies. All of these things are assets, and the organisation reflects either the management of these assets or growing the customer base to use or contribute to those assets. IT is no different than finance or human resources. Just as the business doesn't give HR or finance discrete budgets for specific business requirements, so too will it realise that it needs to treat IT the same way. Successful SOA, as part of the overall move to EA and the realisation of composite, loosely-coupled, and potentially reusable IT assets, requires not just addressing the aspects of Service creation and management, but also successfully addressing IT portfolio management.
Ronald Schmelzer, senior analyst and founder, is a well-known expert in the field of Service-Oriented Architecture (SOA), Web Services, and XML-based standards. Ron has been featured in and has written for periodicals, and has spoken at numerous industry conferences and in front of some of the largest businesses in the world.
This article was first published by ZapThink.