Albert Wenger put up a good post talking about the challenges faced by their startup portfolio, and how a vertical approach to subsystem division helps scaling the organization. In fact the Web 2.0 landscape is very reflective of this approach. 10 years ago if Yahoo needed an authorization framework they would have built it themselves. Today people use oAuth. Flickr, Twitter, Delicious, Campfire, Meebo, S3... all very focused services that delegate non-core functionality to another service where possible. For those things that are duplicated across services (web frameworks, database backends), nobody cares if they're different... it's hidden behind the service.
This is very attractive for the startup ecosystem. The tangible results have been products that are cheaper to launch, quicker to market, and easy to adapt to customer feedback. But how does it apply to the enterprise?
Issue 1:
For better or worse, in large engineering organizations people tend to care that the common horizontal components are indeed common. If you work in a 100+ person engineering organization, and the rest of the team is using Spring + Struts for web development, it's usually a tough sell to start using Rails. If the organizations insists on this homogeneity, your vertically sliced org is cross cut by the commonality police, hampering the agility of the vertical team. There are good reasons for this. Somebody needs to support and test the thing. If nobody else can deal with what you just built, it doesn't have a path to market, and is therefore useless.
Issue 2:
It's easier to add 1 person or 1 feature to an existing service than it is to spin up a whole new service team. Most organizations usually don't have the luxury of five new reqs to apply to a service. And they're also hesitant to carve out five people from existing teams to spin up a new service. So teams and services are usually built by accretion. The result is usually a gradual march to collapse, as services become bloated and so difficult to maintain they need to be replaced.
Issue 3:
The organization only has capacity for a limited number of products. A startup of 5-10 people can fully support the development, launch, and marketing of a vertical service. In a large organization, the amount of infrastructure required to take a product to market means that unless you have a multi-million dollar revenue stream guaranteed in year 1 your chances of getting marketing, sales, training, doc, etc. spun up to support you are very small. That means actual releases are larger than individual services.
Issue 4:
Coordination challenges across vertical services. This ties in to issue 3. Because a product release is a composition of multiple services, there is a desire for tight coordination across these services. Contrast this to the Web 2.0 world. Basecamp uses Amazon's S3 storage service. They are under no illusion that they can call the shots on S3's feature roadmap. And even more important, they would not plan for a release based on features that S3 has not committed to. In the enterprise, these rules don't apply. Feature roadmaps for a collection of services are determined at the same time, and management hopes to coalesce them all into product at a predefined future date.
Possible Solutions
To address issue 1, the organization should focus on service capability, not underlying implementation. To support this, service teams will need to be self sufficient, and should make implementation decisions as a team. It needs to be tested. Involve quality engineering in the technology selection. It needs to be doced. Involve doc. At the end of the day the customer rarely cares if you use VB or Python to get them their value.
To address issue 2, the entire organization needs to be focused on keeping services focused on their core function. When somebody needs feature X, run through the list of services. Teams should be willing to say no to features not because they don't have capacity, but because the feature corrupts the purpose of the service. If the feature doesn't fit with any project, spin up a new service rather than accrete it onto an existing project. This requires the organization to be flexible, to be willing to work on new things, and to give up old responsibilities. It also demands a rejection of empire building. You should take more pride in your project being small, focused, and absolutely fantastic at what it does, rather than measuring your worth by the number of people on your project.
Issues 3 and 4 are the stickiest. In the enterprise the opportunity for experimentation is much lower than it is for a consumer web offering. Perhaps one option is to create a "labs" organization, that releases products for free for use by bleeding edge customers. Services that are vetted through the "labs" channel could be productized at a later date.
Coordination problems could be solved by eliminating planning that spans services. Take a snapshot of service capabilities, and plan from there. This likely slows down development to a certain extent, but also makes individual plans more predictable, and significantly reduces coordination challenges.
Wrapup
While challenges exist in the enterprise, I think it's worthwhile to look at how we can make vertical slicing of the org work. The advantages realized by Web 2.0 companies are compelling, and we definitely have challenges with our current horizontally structured groups.
This is very attractive for the startup ecosystem. The tangible results have been products that are cheaper to launch, quicker to market, and easy to adapt to customer feedback. But how does it apply to the enterprise?
Issue 1:
For better or worse, in large engineering organizations people tend to care that the common horizontal components are indeed common. If you work in a 100+ person engineering organization, and the rest of the team is using Spring + Struts for web development, it's usually a tough sell to start using Rails. If the organizations insists on this homogeneity, your vertically sliced org is cross cut by the commonality police, hampering the agility of the vertical team. There are good reasons for this. Somebody needs to support and test the thing. If nobody else can deal with what you just built, it doesn't have a path to market, and is therefore useless.
Issue 2:
It's easier to add 1 person or 1 feature to an existing service than it is to spin up a whole new service team. Most organizations usually don't have the luxury of five new reqs to apply to a service. And they're also hesitant to carve out five people from existing teams to spin up a new service. So teams and services are usually built by accretion. The result is usually a gradual march to collapse, as services become bloated and so difficult to maintain they need to be replaced.
Issue 3:
The organization only has capacity for a limited number of products. A startup of 5-10 people can fully support the development, launch, and marketing of a vertical service. In a large organization, the amount of infrastructure required to take a product to market means that unless you have a multi-million dollar revenue stream guaranteed in year 1 your chances of getting marketing, sales, training, doc, etc. spun up to support you are very small. That means actual releases are larger than individual services.
Issue 4:
Coordination challenges across vertical services. This ties in to issue 3. Because a product release is a composition of multiple services, there is a desire for tight coordination across these services. Contrast this to the Web 2.0 world. Basecamp uses Amazon's S3 storage service. They are under no illusion that they can call the shots on S3's feature roadmap. And even more important, they would not plan for a release based on features that S3 has not committed to. In the enterprise, these rules don't apply. Feature roadmaps for a collection of services are determined at the same time, and management hopes to coalesce them all into product at a predefined future date.
Possible Solutions
To address issue 1, the organization should focus on service capability, not underlying implementation. To support this, service teams will need to be self sufficient, and should make implementation decisions as a team. It needs to be tested. Involve quality engineering in the technology selection. It needs to be doced. Involve doc. At the end of the day the customer rarely cares if you use VB or Python to get them their value.
To address issue 2, the entire organization needs to be focused on keeping services focused on their core function. When somebody needs feature X, run through the list of services. Teams should be willing to say no to features not because they don't have capacity, but because the feature corrupts the purpose of the service. If the feature doesn't fit with any project, spin up a new service rather than accrete it onto an existing project. This requires the organization to be flexible, to be willing to work on new things, and to give up old responsibilities. It also demands a rejection of empire building. You should take more pride in your project being small, focused, and absolutely fantastic at what it does, rather than measuring your worth by the number of people on your project.
Issues 3 and 4 are the stickiest. In the enterprise the opportunity for experimentation is much lower than it is for a consumer web offering. Perhaps one option is to create a "labs" organization, that releases products for free for use by bleeding edge customers. Services that are vetted through the "labs" channel could be productized at a later date.
Coordination problems could be solved by eliminating planning that spans services. Take a snapshot of service capabilities, and plan from there. This likely slows down development to a certain extent, but also makes individual plans more predictable, and significantly reduces coordination challenges.
Wrapup
While challenges exist in the enterprise, I think it's worthwhile to look at how we can make vertical slicing of the org work. The advantages realized by Web 2.0 companies are compelling, and we definitely have challenges with our current horizontally structured groups.
