Top 10 SOA Pitfalls: #2 - Unclear ownership / Project based funding
Join the DZone community and get the full member experience.Join For Free
in the world of standalone applications, there is typically a clear sponsorship and ownership of an application. there is also a single project with one project manager. the systems could be small or big, but the pattern remains the same. funding is based on a business caseand can be easily defended.
in soa world, the story is different. there are the usual projects,each having their own objectives and often reluctant to work on generic services or enterprise components. if the ownership and funding forthese components and aspects are unclear then chances are high thatnothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things onenterprise level go wrong (e.g. security).
several projects working together is not a bad situation, but thereshould also be a soa steering committee and soa competence center wellfunded and supported by company board.
the problems related to the unclear ownership / project based funding pitfall are:
many projects with own interests
there is usually an enterprise architect or someone else expecting separate projects to deliver reusable services and deliver according tothe enterprise architecture. the projects are business-driven, but often projects only target one aspect of the business strategy. exposing the services to others and making them reusable conflicts with direct business interests. it requires additional effort for a project to generalize services and expose them to others; as apposed to justusing the functionality of the services in the project itself only. especially waterfall projects have this problem, because thisreusability aspect is quite difficult to plan in advance.
single large soa project
other companies define a single large soa project which delivers "soa"more or less as a product. this is strange, because soa is an architecture style and not a product. defining a business case for soa is difficult. the usual consequence of an unclear business case is that soa itself becomes the goal. the real goal is achievement of business requirements like faster time-to-market or cost reduction by better information and it resources reusability.
in companies where several projects are delivering business products insoa fashion everybody is talking about generic services and many projects claim to build these. in practice, the projects are building these services for themselves and don't really gather requirements fromother projects or departments. again, why should they? it costs significant effort / money and creates project risks.
it is a good practice to centralize services, which are not directly bound to one particular domain or department. these are often technical services. for example, security (authentication, authorization, auditlog), message routing, reference data. but, what about transformation services specific to one business domain? in soa projects, there is a tendency to centralize as much as possible. however centralization could cause more troubles. as an example, one problem is that it becomes very difficult to define how responsibilities are divided. a shared responsibility mostly results in no responsibility. the main question is who is paying for development and maintenance.
the root cause of these problems can be found in unclear ownership and project based funding. it can get very messy if this is not organized well. the following are possible solutions:
soa competency center
with any soa initiative, there should always be something like a soa competency center. eric roch gives an explaination on how to organize such competency center. this is a team of people from different areas (technical integration specialists, developers,architects, business consultants) which are pro-actively solving the mentioned problems. this team has independent funding and has a short term delivery of results in short iterations. this team does not only deliver underlying infrastructure and middleware, but also generic, reusable, domain-independent services. domain-specific services will still be delivered by normal projects. in addition this soa competency center can also support projects in variety of other ways (making services reusable, middleware integration).
create market within the company
the projects need to invest in enterprise aspects. the investment canbe covered by having other departments/projects pay for it when services are needed. this is usually a single payment for requirements gathering and development effort.
the participants of the steering committee are representatives from departments. they discuss and make the decisions about enterprise subjects. the budget is determined by company management. the steering committee is also the sponsor and budget-holder for the services delivered by the soa competence center.
guerilla tactics (from
) if you are an enterprise architect
if the projects / departments are reluctant to cooperate, you have always guerilla tactics:
- create a gang of architects from all these projects and make themdo the dirty job. project managers often don't really understand whatarchitects do anyway. in this ways enterprise aspects are funded by the projects secretly.
- threat the projects with external legislation, security aspects, and anything else that you can think of.
- steal the enterprise subjects / components (core services andentities, logging, security) and hold them hostage. the projects will have to work with you and deliver these with their own budget.
having clear ownership and funding for enterprise components and aspects like security, logging, message routing, message transformation, generic services, esb, and so on solves not only the problems during development, but especially in production when operational aspects become essential.
next week rik de groot will take us to #1...
Opinions expressed by DZone contributors are their own.