Note: You are experiencing only the raw content of this site, without the intended layout and design. Either your browser has ignored the Cascading Style Sheet (CSS) files for this site, or you are using an outdated browser which does not support Web Standards. Learn more.

EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology

Read and respond to what the EDS Fellows have to say about the future of technology on EDS' Next Big Thing Blog on eds.com.

Effective Re-Use - Using SOA to Preserve and modernize your IT Investment

by Alex Cameron

It has become apparent to me that the approach to re-use in the past has been somewhat flawed, primarily because the asset's value and place in the enterprise has not assessed.

In my previous SOA article, I stated that, at least to me, this explains the failure of past initiatives, simply because they could not address the high level business functionality. The reason being is that these initiatives tried to drive re-use from a programming paradigm rather than from a business perspective. Although there are initiatives underway to provide a management framework , these will fail as well if they do not address the value of the asset to the business and its cost to support and maintain.

In the graphic (below) I have attempted to show how artefacts might be categorized in terms of applicability to the enterprise:

• Level 1 - relevant to the coder or developer
• Level 2 - relevant within the Project Domain
• Level 3 - relevant to the Business and Enterprise

These categories highlight what we should already know, and that is that code level re-use is not applicable at the enterprise level. It will fail simply because the value proposition is just not there, and the cost to maintain is disproportionate because it is difficult to manage and maintain and most importantly, the artefact cannot be expressed in business terms. Level 3 is effectively the Application, Business Architectures, etc. within TOGAF.

So if you now argue that for a large organization, it would still be good to share this bit of code, then think of this. That bit of code is probably already in an application somewhere in the enterprise and another instance of it is just going to increase your complexity, why not just reuse the service or component where it was originally used - or at least think of it in these terms and you will begin to see the method of solving the problem.

To me, this diagram clearly demonstrates the benefit of unlocking the value of our existing applications, and where those artefacts should be managed within the enterprise. For example, Level 3 artefacts should be managed within a enterprise governance framework. SOA Services are a key aretefacts that are managed at this level.

The method of unlocking the existing IT value is through a modernization strategy. To me, SOA offers the opportunity to first decouple the essential and business defined services (to help reduce the complexity) and secondly to begin the integration of the services to extend the functionality and value of those services (agility).

SOA should therefore be a key consideration of any modernization strategy, and its position on the chart reflects this.

Published Wednesday, June 21, 2006 2:10 PM

Subscribe to this post's comments using RSS

Comments

Posted by James Taylor Wednesday, May 10, 2006 9:46 PM

Re-use cannot be driven from either a purely programming or a purely business perspective. You need an environment, like that provided by business rules management, in which the business and IT can collaborate over reusable components. Such a collaboration is the most effective way to address the value of the asset to the business and its cost to support and maintain.
http://www.ebizq.net/blogs/decision_management/2006/05/what_level_of_reuse_does_busin.php

Posted by Alex Cameron Thursday, May 18, 2006 6:28 AM

James, I thought long and hard about how Modelling MDA and UML might fit into this scenario, and eventually left them out using the logic that the were generally not re-usable assets per se and that they were more tightly aligned to the enerprise . I felt that what would be more re-usable and a more clear point of leverage would be reference frameworks. This is how I also see business rules and BI as they don't lend themselves to re-use unless embedded or as part of a service. Now my logic maybe flawed and the beauty of these types of discussions is that they test your views and logic and provide another perspective

Posted by Martin Holzworth Tuesday, June 20, 2006 6:23 AM

Excellent point Alex. Reuse is not a new problem, and if you look around EDS there are probably 20+ different groups trying to solve it, independently. I’d like to extend your argument by suggesting that there are 8 pain points in EDS now relating to Reuse:
Repositories: Where are the repositories of reusable assets?
Consumption: Where do I use the reuse assets?
Submission: Have a reuse asset. Where can I submit to reuse repository?
Certification: Quality (certification) of the reuse assets
Maintenance: Currency of the information – who manages the updates
Licensing and IP issues: Who owns IP rights and licensing
IT Governance: Who manages the IT Governance through the SLC of the asset
Business Value – ROI: Estimating the potential reuse value of assets to determine investment viability.
And whilst we can build repositories to store these assets, and mandate their use, they will continue to fail unless these 8 issues are solved.
I’d also like to extend Reuse to be more than code. Reuse is much more than that and needs to include:
Requirements - (Business requirements, estimates, use cases, models),
Analysis & Design - (models, architectures, patterns),
Build - (code, real-time services, run-time technical assets, non run-time technical assets), Integrate & Test (test cases, metrics),
Deploy - (guidance, bill of materials, templates).
SOA is one part of the Reuse problem in that it promotes reuse of real-time services but to me the full ROI will only be achieved when you address it through the how lifecycle and not just through services.

Posted by Scott Hatanaka Thursday, June 29, 2006 6:08 PM

I think you are forgeting the importance of risk in decoupling and the duplication of system performance. Most CEO's and CIO's are very risk adverse to change. This is the life's blood of their business, and they are not going to risk it, just to make it more convenient for us. The paradigm for modernization has changed, too, with IFL, zaap and ziip engines and vWLC. IBM's SOA message is to front end Linux to people's existing system.
Doing the integration first, and then the decoupling second. A far safer pathway.
The paradigm has made their process, cheaper, with a quicker turnover, safer and with a better performance factor than most platform migrations. This is the main reason why Gartner thinks that migrating 500+ MIP workloads is not recommended, why the multi-platform CMG thinks our strategy is now odd and why SUN has been taking a beating in enterprise level computing over the last 5 years. The issues with Sun are NOT with Linux and unless Sun addresses them soon, the prediction, in April, of their demise in THE ECONOMIST, will most likely come true. Their path is very similar to what happened to DEC over a decade ago.

As for that bit of code being in multiple places... the issue increases not decreases with server farm. To truly eliminate the complexity requires going to a utility/grid computing model. A model that has been available in the mainframe world for 10+ years.... but EDS management didn't/couldn't take advantage of or seem to understand, costing EDS 10s of millions of dollars per year. SOA's impact to code reuse is limited if we don't adopt a utility/grid model. It's impact will be similar to what CASE was in the 90s. I am dubious that a utility/grid model will ever be implemented at EDS, no matter what the platform. The issues are political, not technical.

Posted by Tom Hill Wednesday, July 19, 2006 6:23 PM

Scott - I think you have well-formed insight into the nature of the problems (minimizing risk, masking complexity, while maximizing value) and the breadth of solutions that will be offered in the marketplace. Clients are demanding that we make the utility/grid model work again and I believe we (EDS, you and I), have the primary responsibility to make it operational on multiple platforms. Innovation in hardware and software is one of the reasons I’ve liked Sun since 1984 - I’ll be hard-pressed to ever count, a company of innovators, out of the picture.

Posted by Alex Cameron Wednesday, August 02, 2006 7:57 AM

Scott,
further to Tom's comments - I agree with your observations. I have indeed met clients who have systems being put under legislation to minimise change. So your point is taken - the strategy for implementing SOA was not discussed in the article but in all but green field situations, it has to begin with abstracting the existing components to not only de-risk but because they are hard to change (ie the mess we are in at the moment) them and to have a strategy of supplementing them with new services to enhance the application and to be able to deliver new functionality. I addressed this in the blog entitled "classification of services" and it aligns with your point of "integration first and decoupling second". This certainly is vital that our architects align with this thinking..
Onto your point about utility and grid computing - the real issue is the same code for different purposes this drive complexity unless it never changes (which does not happen). I wasn't addressing the issue of scalability or multiprocessing, but the issue of trying to maintain different code bases at an enterprise level rather than at a granularity relevant to the business.
However I do think that achieving the ultimate state of highly scalable systems has to be founded on reducing the complexity of applications through SOA. Now the point here is that complexity can be defined as the future state as well. So introducing an SOA approach now stops our existing systems from getting more complex – so at least in the first instance (by taking your integrate and decouple approach) we have halted the complexity spiral and gotten onto a safe strategy of being able to build future functionality into the application rather than modifying the existing application.
By identifying services of the appropriate granularity (achieving business relevance - as per my diagram) we put ourselves on the path towards achieving an future full SOA, and we will have also proven our ability to then tackle the “decoupling” exercise in the future.
So by slowly increasing the level of granularity to level consistent with a achieving business relevance (as per my diagram) we can move towards the utopian state where all services are integral, can scale easily (if not automatically through virtualisation) and we achieve greater utility and greater ability to improve functionality through easily augmenting overall functionality with new services with a prudent choice of services that rarely need to change (agility).
This ideal has to be consistent with the Grid indeed perhaps - SOA is the Grid! - On this topic, I read a very interesting article in the Microsoft Journal a few weeks ago, on the rise and rise of database architectures. I wonder if all services in the future will sit within a integral database, with a small OS to run the database, resulting in a very compact service that is fast scalable and without the need for the huge Operating Systems of today. So all services now becoming fully contained with their own data - a place where everything is a service and the ESB is the infrastructure-