In this post I will drill down into the conceptual 2.0 service architecture introduced in part 1 of this series.
2.0 services first evolved in the web startups community and permeate the online consumer ecosystem today. It would not be a stretch if one were to imagine that the vast majority of these services have evolved to their current state organically and over time in response to the evolving visions of their founders, consumer feedback, and in certain cases, market opportunities. Getting stuff done and released as fast as possible with minimal CAPEX & OPEX, enticing users, testing the waters, and constantly & incrementally optimizing investments/course correcting along the way…constitute the norms of execution in the consumer web startup ecosystem. While agile practices are good and recommended in general for 2.0 service initiatives of all kinds (consumer web or enterprise/business), thinking through related hard problems at the outset to guide resource investment decision making is also highly recommended. The following for instance are some of the top of the line challenges of significance to consumer web startups and enterprises:
Consumer Web Startup Challenges
- Cold booting a user community (How do I get from 0 to 100K users?)
- Operational infrastructure scalability (What happens when I get from 100K to 500K/1M users?
- Sustaining active user engagement (How do I keep my users plugged and actively using my service?)
- Connecting with untapped long tail user segments (How can I connect with users who are not Web 2.0 savvy?)
- Predictable Monetization (How do I make predictable money to keep my lights on?)
- Build v/s Buy technology implementation investments (Do I need to build everything to get my service up & running?)
Enterprise Challenges
- New technology investments – Build v/s Buy v/s Subscribe, Maturity, Familiarity, TCO
- Integration with existing line of business IT investments
- IT Ops Scalability
- Cold booting external community engagement initiatives
- Internal cultural barriers for adoption
- Measuring ROI
Identifying the challenges of pertinence to a 2.0 initiative and formulating a plan to account for them does not have to be a long winded multi-month/year process. These aspects can be thought through in an agile manner to arrive at a base set of parameters that guide scalable & adaptable investment decision making to enable agile, incremental, and evolutionary progress.
The Conceptual 2.0 Service Architecture introduced in part 1 of this post and shown below can serve as a framework to guide this process:

I will now drill into the layers and boxes of the conceptual architecture in the remainder of this post.
Infrastructure
At the bottom of the stack we have the core infrastructure with the components required to keep a service functional at its guts. This layer includes a server operating system and bread & butter services like a web server, file/unstructured content storage, a DBMS, networking services, and messaging services. Virtualization capabilities may also be a key component of this layer depending on the service type and scalability requirements.
LOB Systems
This layer is typically Enterprise/Business specific and comprises the line of business applications & services. Though not usually seen in a consumer web startup’s infrastructure, planning for LOB system integration services higher up the stack can enable interesting business opportunities for consumer web startups whose services have potential in a business context. The scenario that I will discuss in part 3 of this post will illustrate this opportunity.
Foundational Services
The foundational services layer is largely common across 2.0 services and includes the following:
- Unstructured content management
- Structured data access
- LOB System Integration to enable integrating a 2.0 service with line of business applications/services – of specific relevance to the enterprise/business context
- User identity management
- Services that enable social dynamics and experiences
- Search service(s) that span unstructured content, structured data, LOB systems, external services, and social metadata
- Usage Analytics to measure/analyze service usage and guide investments
- Synchronization to enable partially connected & multi-channel experiences for consumers
- Monetization services like advertisements, billing/payments etc
In general, enterprises (and consumer web startups, in many cases) should look to integrating with and leveraging existing best of class service offerings that enable these capabilities v/s re-inventing the wheels.
Custom Services
This is the layer at which Enterprises and the vast majority of Web Startups should ideally invest maximum resources & efforts in the context of custom service development. For Enterprises, it is the layer at which customized business value enablement is materialized. For Web Startups, it is the layer at which consumer value differentiation is materialized.
Service Interfaces/APIs
The Services Interfaces & APIs layer is crucial to enabling multi-channel service consumption, service integration (with external services), and service extensibility/composition. This is the layer at which the core capabilities are wrapped and exposed as standards based web services, syndication feeds, and scripting & programming language wrappers to enable the mentioned scenarios.
Delivery Channels
At the Delivery Channels layer it is important to be able to account for multiple channels of service delivery that have gained/are gaining adoption in the users ecosystem. In addition to the web browser…channels like mobile phones, PC apps, device consoles, external services with potential to integrate with & mutually benefit from, and web service repositories used to enable user mashup experiences are all delivery channels of relevance to achieving the maximum user reach potential. Having a well defined and implemented Service Interfaces/APIs layer is the key to materializing multi-channel service delivery.
Tools
On the tools edge, it is important to account for tools that can address the requirements of a) personnel responsible for developing and operating the service viz. Developers, Designers, and Administrators, and b) users who consume the service.
On-premise v/s Cloud v/s Hybrid
Not depicted explicitly in the illustration above are the conceptual solutions infrastructure deployment options available to materialize the layers and building block components of the Conceptual 2.0 Service Architecture. Choosing between on-premise infrastructure investments, cloud service providers, cloud hosting providers, or a hybrid model, is yet another decision making exercise in the context of 2.0 service initiatives.
In Summary…
A good understanding of the conceptual architecture/framework described above can be useful in navigating the maze of options available and making optimal investment decisions in the context of addressing the 2.0 service development challenges summarized above in this post. In parts 3 & 4 of this post (to follow shortly), I will discuss realistic scenarios (a consumer web scenario and an Enterprise scenario) to illustrate the application of this conceptual architecture as a framework for such decision making.
That’s it for today…stay tuned for more!
Cheers
Karthik