Outside-in SOA: SOA for Small and Medium Businesses
In the previous section, we witnessed the transformation from inside-out to outside-in in large companies. In this section we will see that the same evolutionary process can be naturally extended to small and medium businesses (SMBs.) The difference is that the processes take place on whole ecosystems instead of a single large company.
By their very nature, SMBs do not usually have the luxury of a large IT budget, or a large IT department. Many of these companies have only a few IT literate employees acting as part time IT support. They would not be able to afford the "internal-only" SOA adoption model. Hence SMBs do not have the critical mass to establish the internal services portfolio for the inside-out process.
However, if we assume that large enterprises become first adopters for SOA, and in so doing a market for services gets created, SMBs can leapfrog the whole inside-out process. SMBs can start purchasing services from the outset. In fact once the ecosystem matures the inside-out model will become as obsolete as it is building in-house applications from the ground up today.
In a mature SOA environment, SOA compound applications will be built out of predominantly outsourced services. Figure 7 illustrates the concept. A well defined business process (such as purchase order creation and processing or a bank transaction) is represented by a set of SOA services instantiated by different users and integrated into a user solution supporting and driven by business need. In essence, the process of picking and choosing the right pieces for their businesses by SMB owners would look very much like a mash-up in the Web 2.0 world today.
Such an approach to adopt SOA could lead to a surprising result: the experience from the efforts in building strategies for instituting SOA in large organizations suggests that at some point in the maturation of the SOA market, large organizations will not be a precondition for SOA adoption. SOA can flourish in a small organization environment as well. This conclusion is also aligned with the very concept of openness and standardization of Web services. The processes are architecturally sound and technically feasible, even though there are technical and social behavior hurdles to overcome.
The adoption of SOA in SMB space will take place under a different dynamic: instead of reuse from within, or across organizations in a large enterprise, considered a necessary condition for critical mass, we will see the same critical mass, but with reuse now happening across whole economic ecosystems.
In other words, we are proposing a model for SOA deployment that depends on multiple ecosystem players providing composite applications that are used to build more complex SOA-style composite applications. Under this environment we can expect a degree of specialization where the individual services are provided by smaller players with the appropriate expertise. This situation is illustrated in Figure 8. To distinguish this approach from the traditional internal only or inside-out approach to SOA specific to large enterprises, we call it outside-in SOA. The outside-in approach is not exclusive domain of SMBs; it can also take place in large enterprises as described in the previous section.
Who has a vested interest in making the transformation to outside-in SOA take place? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for another player. The whole ecosystem benefits when the value received greatly exceeds the cost expended for purchasers, and when sellers realize additional demand for products and services because of this value.
Consumers of services stand to gain because of the lower cost overall for procuring application capabilities via compound applications through compound services. Software tools vendors will benefit through offerings that target an outside-in SOA environment, and likewise vendors of technology building blocks. These building blocks must have SOI capabilities that support automated provisioning and the concept of virtualized appliances.
Relationships among services providers will grow in fairly complex ways. Services providers will become both providers and consumers of services. Even companies that are not traditionally services providers like Amazon.com are beginning to develop a surplus service capability. These companies will start selling these services to create additional revenue streams. Actually Amazon.com is not a good example because it is not really a small company. This model can scale down to 10 --100 employee value-added reseller (VAR) type of companies.
Canonical service components, that is, services designed as services from the ground up, are not essential to make this scheme work. The traditional stovepiped applications in Figure 5 can be retrofitted through middleware shims to behave as composable services in a manner not unlike screen scraping programs are used to extend the life and usefulness of legacy mainframe applications. The barriers to the outside-in model are lower than they appear at first analysis because the industry does not need to wait until a large portfolio of reusable services becomes available.
As service technology matures and more players partake of the market we can expect a rich cottage industry for services to develop with offering available to build most any application imaginable. This market will be highly diversified across geographic regions driven by local needs and regulations. In this environment it simply will be cheaper to build specific functionality by contracting out constituent components in the marketplace rather than building the same functionality wholly in house.
The paradigm of the automobile or the aircraft industry, with a huge supply network, will also apply to software applications.
The outside-in approach differs from traditional outsourced arrangements: the negotiation of an outsourced payroll function may involve months and real people at the table. On the other hand, outside-in transactions will be eminently automated and highly dynamic through automated registries and discovery services and using open standards. One such transaction might take from a fraction of a second to no more than a few seconds.
