Now that's a strange combination. Why should I, as an #enterprise architect, be concerned about project management? And from the other end, why should I, as a project manager, bother about #SOA (or whatever friggin technology the project is about)? Well, the short answer - SCOPE.
SOA is an enterprise architecture paradigm, enterprise-wide architecture-principles within which the technology solutions should be implemented. To maintain an efficient architecture, it pays to be consistent across the enterprise. Which is why, SOA can provide an enterprise-wide view of the solution guideline. The 30,000 feet view of how should the "right" solution look like. The scope for SOA, therefore, is the entire enterprise. That of course, once the definition of enterprise is established.
Projects, by definition, have a more closely and clearly defined scope within that enterprise universe. These are therefore a subset of the enterprise wide SOA scope. Now that's simple. So what's the big deal ? Things get trickier to manage when it comes to delivery timelines for the projects. The architecture can well be an evolving and improving entity, with no clear or stringent timeline requirement. Its primarily about doing the right thing. While the project needs to be delivered in a defined time-frame, and within a defined budget. Project level decisions are governed by project level factors like timelines, budgets, resources etc. Since the architecture has a wider scope, more often than not, the architecture changes and decisions interfere with the project delivery.
That's when usually the project sponsors put their foot down and start dictating the way forward. From there on, its a power tussle. A "win-lose" or "zero sum" game rather than a game with a possible win-win outcome. The manager with more political muscle takes over. Exceptions are made in the processes. Architectural principles are bent to manage delivery. And while the delivery of the project/program gets done, there's a good chance that what's delivered becomes "Technical Debt" well before its life expectancy. I'm sure we've all seen cases where a model based service design and implementation was forgone to make way for a quick fix point-to-point solution to meet the delivery timelines. And the very next project in the pipeline would have an additional piece of work to build an adapter around this solution to make it compatible with the overall solution. And the story goes on.
So what's the solution? Simply put, the harder it is to follow the rules, more the possibility of the rules being broken. Its imperative then for the #EA to be quick and clear on defining and socializing a minimal basic standard and guideline to be followed, leaving enough room beyond that for the projects to chose an implementation pattern. A "Strategy Pattern" is a good (although simplistic) example of that balance. Have a checklist to define and evaluate (financially & operationally) if a technical solution is a long term "technical asset" or "technical debt". If a solution takes a deviation from the architectural guidelines, and still qualifies as technical asset, all good. Because in the end, the business stakeholders are interested only in ensuring that a solution gets delivered within a cost and time frame. The level of perfection for that solution is immaterial to them. Which is why Delivery usually scores over perfection.
More on the "How" part of the solution in my coming posts.
PS: In broad terms, this is essentially the gap in an organization's #Strategy function and its Implementation function. "Architecture" being the enabler for alignment to strategy, and "Project Management" being the management of a specific piece of work under that umbrella. In this particular case its about "Project Management For SOA implementation" vis-a-vis "Project Management Vs SOA"
That's when usually the project sponsors put their foot down and start dictating the way forward. From there on, its a power tussle. A "win-lose" or "zero sum" game rather than a game with a possible win-win outcome. The manager with more political muscle takes over. Exceptions are made in the processes. Architectural principles are bent to manage delivery. And while the delivery of the project/program gets done, there's a good chance that what's delivered becomes "Technical Debt" well before its life expectancy. I'm sure we've all seen cases where a model based service design and implementation was forgone to make way for a quick fix point-to-point solution to meet the delivery timelines. And the very next project in the pipeline would have an additional piece of work to build an adapter around this solution to make it compatible with the overall solution. And the story goes on.
So what's the solution? Simply put, the harder it is to follow the rules, more the possibility of the rules being broken. Its imperative then for the #EA to be quick and clear on defining and socializing a minimal basic standard and guideline to be followed, leaving enough room beyond that for the projects to chose an implementation pattern. A "Strategy Pattern" is a good (although simplistic) example of that balance. Have a checklist to define and evaluate (financially & operationally) if a technical solution is a long term "technical asset" or "technical debt". If a solution takes a deviation from the architectural guidelines, and still qualifies as technical asset, all good. Because in the end, the business stakeholders are interested only in ensuring that a solution gets delivered within a cost and time frame. The level of perfection for that solution is immaterial to them. Which is why Delivery usually scores over perfection.
More on the "How" part of the solution in my coming posts.
PS: In broad terms, this is essentially the gap in an organization's #Strategy function and its Implementation function. "Architecture" being the enabler for alignment to strategy, and "Project Management" being the management of a specific piece of work under that umbrella. In this particular case its about "Project Management For SOA implementation" vis-a-vis "Project Management Vs SOA"
No comments:
Post a Comment