SOA repository is the technology enabler for asset reuse. During design time, project teams search the repository for scheduled and published services to determine whether any asset can be integrated and assembled into their solution without building it.
Several scenarios may happen:
1 - The service is found in the repository and can be readily reused
2 - The service is found in the repository, but the consumer has to wait until it is available
3 - The service is found in the repository, but requires change (minor -> major)
4 - The service is available, registered, but couldn't be found in the repository
5 - The service is available, but not registered so it couldn't be found
...
There are different solutions to the problems above. At the end, it is the job of the SOA CoE to socialize reuse and promote services. The rate and level of reuse is a function of organizational complexities (i.e. culture, CoE model, process) as well as development approach (prescriptive and formal unified process vs. highly interactive agile methods).
Also, as teams collaborate on service production and consumption, they engage in frequent social interactions. Repository vendors should look beyond basic collaboration support (i.e. notification, workflow) and integrate social computing capabilities in their solutions to generate excitement and overall vitality, enhance productivity & knowledge which should facilitate and contribute to more effective reuse.
Showing posts with label Reusability. Show all posts
Showing posts with label Reusability. Show all posts
Monday, December 08, 2008
Delivering reusable services...Why does it fail?
IT asset reuse can be a force multiplier in reducing costs (TCO) and enhancing operational productivity (ROI).
Assets can range from knowledge delivered in an email to models, frameworks, applications... Regardless of asset type and whether they are tangible or specified formally, critical business operations may be dependent on them.
Service reuse is one of the most important objectives of SOA, but most projects struggle with it. Service reuse is typically achieved at low rates (or levels) or not at all. In terms of producing reusable services, the issues are related more on the approach rather than technology. It should be planned early on.
Current SOA approaches and methodologies focus on service reuse during service design & specification:
(1) Projects are reviewed by SOA CoE/CoC
(2) Candidate services are identified
(3) The CoE guides in designing reusable services and specification
(4) The project team rejects the design as too complicated/over-engineered that would delay delivery & impact schedule
(5) Lots of communication goes back and forth between the CoE and the project team over the merits of the design, enterprise benefits...
(6) The Issue gets escalated to senior leadership team
(7) After a few rounds of emails, the executive decision is to park it for now and revisit in the future
(8) The project team moves forward with building something that's specific to their project
The reality is that projects have no incentives for building reusable services. They are routinely measured by how consistently they meet the schedule and budget. By the time we get to service design, it is too late and difficult to balance the efforts to develop reusable services against project costs and deadlines. Incentives for building reusable services should be seeded at project inception time.
Assets can range from knowledge delivered in an email to models, frameworks, applications... Regardless of asset type and whether they are tangible or specified formally, critical business operations may be dependent on them.
Service reuse is one of the most important objectives of SOA, but most projects struggle with it. Service reuse is typically achieved at low rates (or levels) or not at all. In terms of producing reusable services, the issues are related more on the approach rather than technology. It should be planned early on.
Current SOA approaches and methodologies focus on service reuse during service design & specification:
(1) Projects are reviewed by SOA CoE/CoC
(2) Candidate services are identified
(3) The CoE guides in designing reusable services and specification
(4) The project team rejects the design as too complicated/over-engineered that would delay delivery & impact schedule
(5) Lots of communication goes back and forth between the CoE and the project team over the merits of the design, enterprise benefits...
(6) The Issue gets escalated to senior leadership team
(7) After a few rounds of emails, the executive decision is to park it for now and revisit in the future
(8) The project team moves forward with building something that's specific to their project
The reality is that projects have no incentives for building reusable services. They are routinely measured by how consistently they meet the schedule and budget. By the time we get to service design, it is too late and difficult to balance the efforts to develop reusable services against project costs and deadlines. Incentives for building reusable services should be seeded at project inception time.
Subscribe to:
Posts (Atom)