Moving from a project-based culture to a product-based culture
Many people have frequently stated that the biggest challenge in adoption SOA is the cultural change. That’s an easy statement to make, but how do we qualify what we mean by cultural change? Merriam-Webster provides this definition of culture:
The set of shared attitudes, values, goals, and practices that characterizes an institution or organization
One of the attitudes and practices that arguably most organizations practice is that of the IT project. Things in IT get done by creating a project. An idea is generated by someone in the organization, typically the business side, a project is defined and funded, IT provides the solution, and the team goes on to the next project. So why is this a problem? Without projects, how would work get done? The problem that this culture creates is the dimensions of the project control all decisions. Here’s a picture that illustrates this.
Projects are wired to create things like this:
The problem is the project boundary is not a system boundary. It’s an artificial boundary. The components that comprise the project solution represent the real boundaries, but because of the project constraints, they’re unable to to set those boundaries correctly, either because they were constrained from performing appropriate analysis to figure out what they should be, or they were told that funding didn’t allow the “right” thing to be created. It looks like this:
When those project boundaries become system boundaries, the result is the monolithic application, which I think we’d all agree is a bad thing. Even where the appropriate boundaries were determined, the project-based organization will likely struggle to match a team to that subcomponent for proper lifecycle management. While many organizations certainly have teams that continue to provide subsequent releases for a solution, those releases are still defined along those original project boundaries, not the correct system boundaries. Coupled with that, project-based organizations think in terms of linear, project lifecycles:
Where organizations need to go is to adopt a product-based culture based upon appropriate system boundaries, not on project boundaries. A product-based culture presumes a lifecycle like this:
Projects should be created to manage the efforts associated with a release of a product, but projects should not be the source of our system boundaries. In addition, the product-based lifecycle has that final activity of monitoring, marketing, and management, the three M’s. All too often, the project-based organization just throws things over the wall when their linear lifecycle is complete, and the only thing that happens is some alert-based monitor to notify someone when something breaks. This step needs to be formalized so that proactive monitoring takes place to increase understanding of how the service is used, including trend analysis to understand why it behaves differently (even if nothing breaks) under certain conditions. The service needs to be marketed to the community to identify new consumers and new requirements. Anyone who’s tried to achieve reuse of software within an enterprise will tell you that successful marketing is critical to this effort. Finally, all aspects of the service must be managed. This means communicating with existing consumers, updating contracts and policies as needed, sharing usage information, and doing everything possible to demonstrate that you have control over everything about this service.
This approach certainly has its challenges. From an organizational perspective, you can’t simply map a team to a given service, because the release cycle for a product may be so long that it can’t keep a team 100% occupied. A better approach is to align organizational teams around service domains, so that the team manages enough services to keep them occupied, but similar enough to allow depth of knowledge in a given area. These could be horizontal domains, focused on infrastructure libraries, or they could be vertical domains, focused on areas of business capability. Odds are your organization will require both, just as it likely has separate teams today that specialize in technical infrastructure typically purchased from a vendor from groups that specialize in more vertical application development.
If SOA could be done as a project, these organizations would be doing it. The problem is that it can’t. Many organizations are tying SOA to some major initiative which has significant breadth of scope such that the right boundaries for services can be determined, however, if they don’t find a way to transition to a more product-like development model rather than a project-like development model, they’ll still struggle after that initiative is complete.
7 Responses to “Moving from a project-based culture to a product-based culture”
Leave a Reply
[…] I was happy to hear Anne call out the problems with the project-based culture prevalent in IT organizations that I also commented on in April of 2007. There are huge cultural changes that need to be made, but most organizations are not doing so. It’s an extremely difficult problem, because you need to figure out an incremental way of doing it. Anne goes on to comment: So much of SOA is tied up in things like Master DM and ID M and a reasonable DA and BPI efforts and all the EA things people are doing. You have to take this cross-organizational perspective and plan what you’re going to do and not just say, “Oh, I’ve got a new project I’m going to let my developers figure out what services to build.” It’s challenging because you have to think globally but you do actually have to implement on a local level. But you just can’t depend on the local people to figure out what they’re supposed to be doing. They need guidance from above. – Anne Thomas Manes […]
[…] As we increasingly conceive of an enterprise as a set of business capabilities so the focus of governance moves away from inappropriate concentration on technology and onto the portfolio of services that the enterprise needs to realise its goals. In this scenario the implementation of business capabilities is wholly federated to the capability owners who have the right to decide how they implement the services that they offer to the rest of the organisation, resulting in a cascading (and greatly simplified) ‘business architecture’ where organisations only scope and govern services at the level at which they consume them, leaving onward decisions within the remit of their service providers. This might seem to fly in the face of traditional notions of SOA where people bemoan the fact that most organisations are ‘project-centric’ and that there should be less ’selfishness’ but the fact of the matter is that if we charge people with delivering certain value – and we judge them on their performance -then the natural tendancy of human beings is to exclude anything that is orthogonal to the task at hand. This means that rather than force people into situations where they come into conflict over differing priorities we need to realign the way in which people are judged – by charging them with the delivery of a service that meets the needs of the organisation as a consumer – whilst giving them total autonomy over how that service is delivered. This delivers the best of both project and enterprise thinking by more appropriately aligning people’s responsibilities around system boundaries whilst satisfying their need to control their own destiny (this, incidentally, is a subject that was explored more lucidly by Todd Biske here!). Such a model also helps to remove the tensions traditionally associated with inter-departmental integration – discussed by Joe McKenrick here – by realigning departments around the services that they provide, again moving the focus to system boundaries in place of overlapping hierarchies. […]
AMEN!
My opinion on/about SOA…”It should be “SOI” A Service Oriented Infrastructure”
A logical automated system thats[FAST]
://find.access.search.teach.COM
“Think About IT”
I say it a different way.
Mommy Nature does evolutiion, but she sure doesn’t organize the evolutionary process into projects.
[…] “Rethinking IT projects? Think service, not product, focus.” He called out a frequent mantra of mine, which is that we need to get away from the typical project-based mentality and toward a […]
[…] shops don’t have a clue how to do product management. Boy does that sound very familiar (see this, this, this, this, and listen to […]