Top 10 SOA Pitfalls: #2 – Unclear ownership / Project based funding
Posted by Viktor Grgic in the late afternoon: June 16th, 2008
Last week Viktor Grgic explained the Missing skills en this week we’ll continue with #2 - Unclear ownership / Project based funding
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 case and 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 for these components and aspects are unclear then chances are high that nothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things on enterprise level go wrong (e.g. security).
Several projects working together is not a bad situation, but there should also be a SOA steering committee and SOA competence center well funded 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 to the 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 just using the functionality of the services in the project itself only. Especially waterfall projects have this problem, because this reusability 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.
Everything generic
In companies where several projects are delivering business products in SOA 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 from other projects or departments. Again, why should they? It costs significant effort / money and creates project risks.
Centralized services
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, audit log), 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 area's (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 can be 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.
Steering committee
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 CIBIT-DNV) 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 them do the dirty job. Project managers often don't really understand what architects 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 and entities, 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...
Archives
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
[...] by Rik de Groot around lunchtime: June 23, 2008 Last week Viktor Grgic explained Unclear ownership / Project based funding. This week we’ll continue with #1 – Misuse of a SOA to change a [...]
[...] Traduction libre du billet “Top 10 SOA Pitfalls: #2 – Unclear ownership / Project based funding” publié par Viktor [...]