Manage Learn to apply best practices and optimize your operations.

SOA for small and medium businesses (SMBs)

This article discusses the IT needs of and significant differences between both small and midsize firms.

After spending so much time struggling with the complexities and convolutions of enterprise IT, it's important to remember that even small companies still have diverse IT needs. After all, just about every firm has desktop computers, networks, and miscellaneous internal hardware and software, in addition to a Web site and related external IT-related efforts. Even though the IT needs of both small and midsize firms span a wide-range of requirements, there are still significant differences between small companies (less than $50 million in annual sales or fewer than 100 employees) and those at the larger end of the small to midsized business (SMB) scale (up to $500 million in annual sales or up to 1000 employees).

Small businesses rarely have any significant internal integration challenges to speak of, beyond simple collaboration tasks such as file, calendar, and print sharing. However, midsize businesses do have additional internal integration needs, in spite of the fact that they often leverage a single platform for their back office. Many midsize firms, in fact, have some form of legacy problem, in spite of their size. Midrange server and host systems have been available to the midmarket since the 1980s, and as a result, many midsize firms have long since built their IT on such capabilities. What differentiates these companies from their larger enterprise brethren is a combination of the differences in scale as well as the limited IT resources most midsize firms face. Simply put, their inability to spend as much as their large, enterprise competitors means that their legacy problem has been limited to an acceptable scope.

One factor that most small and midsize firms largely share in common is that their distributed computing infrastructures also tend to focus on single, industry-specific applications. For example, retailers center their infrastructure purchasing decisions on single accounting/point of sale solutions, hospitals leverage patient accounting software as well as dedicated clinical and lab solutions, and small manufacturers install focused supply chain and shop floor applications. Even the smallest firms have accounting packages, but companies must be of a certain size before it makes sense for them to integrate those packages with other solutions, such as their customer relationship management, supply chain, or partner support packages.

The relationship between company size and Integration need

The rise of the Internet and the World Wide Web, of course, transformed the business models of many SMBs, as well as their IT needs. After all, on the Internet, no one can tell you're a small company. Now everyone from the smallest mom-and-pop stores to midsize firms in every industry not only have Web sites, but leverage them as an integral part of their business. Of course, the Web represented an additional IT requirement that didn't fundamentally alter the reality of their internal IT organization.

Eventually, small businesses realize they don't simply want to provide an external link to their company, but also desire to embed their capabilities within their customer's processes, leading to an external integration need. The first step that SMBs often take to embed such capabilities is to leverage the Internet for direct computer-to-computer connections between themselves and other companies, including customers, suppliers, and partners. Such Business-to-Business (B2B) integration has long been available to larger companies in the form of Electronic Data Interchange (EDI) and other related technologies, but these approaches have largely been out of reach of the SMB, because of the significant setup and maintenance costs, as well as the inflexibility of the approach. The Internet has now changed this playing field, enabling less expensive ways for SMBs to connect directly to other companies, albeit still in a relatively inflexible manner.

For many companies, Web services have become the preferred approach to enabling simple B2B, Internet-based integration between SMBs and other companies. By leveraging standards-based Web services as a way to interoperate with other firms who also support the same standards, SMBs can realize greatly reduced cost of external integration. Web services-based integration, therefore, has recently become the primary way in which SMBs now choose to integrate with other companies.

An interesting result of this trend is that small companies are able to leverage a single infrastructure to support both Web and Web services capabilities, even though they may have a simple internal IT environment with no need for any additional integration of their internal systems. Indeed, many SMBs outsource the hosting of their Web site entirely, and as such, they will most likely need to outsource their Web services as well. In such cases, much of their business actually runs at their service provider, with little need for integration with their internal IT resources beyond simple interactions for data retrieval or input.

The role of architecture in the SMB

Since the Web plays such a large role for SMBs in their use of Web services, it makes sense that many of them use the cheapest, simplest approach available for implementing B2B Web services interactions. Using approaches such as Representational State Transfer (REST) gives companies a simple, straightforward HTTP-based approach to Web services-based integration that is adequate for the needs of many SMBs. However, as we all know, Web services, and especially REST-based Web services doesn't substitute the need for architecture, and doesn't address more complicated needs for secured, asynchronous, event-driven, and process-driven services that even the smallest of firms crave.

In the absence of an architecture that provides for the loose coupling of such services, the requirement of SOAP adds little but overhead to the services. There is a growing need, however, for externally-facing services to be loosely coupled. When a service is loosely coupled from the software that consumes it, then it's possible to update or modify the functionality of either the service provider or consumer without breaking the other. As a result, SMBs must consider implementing Service-Oriented Architecture as an approach for building, deploying, and managing their services and the environment that surrounds those services, rather than focusing simply on a low-cost, low-complexity protocol for exposing and communicating with service interfaces. Besides, as we frequently discuss, SOA is more than simply about those interfaces, it's also about the contracts and policies that define service usage so that we can gain the benefits of reuse and business agility that the use of a simpler protocol by itself won't give us.

Large enterprises have been gravitating toward SOA because it's particularly useful in complex heterogeneous IT environments that experience frequent, unpredictable business changes. SMBs, however, rarely have complex heterogeneous IT environments, and while they undergo just as many unpredictable business changes as larger companies, they generally have a more controllable IT environment to cope with those changes. When such a dynamic business environment impacts how an SMB integrates with other companies, then it makes sense for SMBs to consider SOA just as much as it does for the enterprise. After all, why should only the large companies get the benefit of business agility, reuse, and lowered cost of IT infrastructure?

Enabling change with Loosely Coupled B2B Web services

To understand why SMBs, even those whose integration problems are solely external, should consider SOA, it's important to see the big picture of the dynamic environment such services participate in. Companies exposing services for B2B consumption have to deal with the fact that they will be building and versioning multiple services many times a year, updating those services with new capabilities, maintaining the contracts and policies associated with the services and constantly provisioning and de-provisioning access to those services many times a year. Correspondingly, a company's customers or partners that consume those services will likewise demand a wide range of service contracts based on their security and protocol requirements, and also require loose coupling such that any changes the SMB makes to their services don't impact the running of their business. As we can see, exposing a service interface is a very small part of the overall challenge of providing services for use with third-parties.

The common theme across all of these capabilities, both on the provider and consumer side, is that of change. If the needs of the service provider and consumer changed infrequently, then there would be no need to go through the hassle of building an architecture to deal with such change. Instead, SMBs would simply agree on an API for B2B interactions. After all, simple APIs for B2B integration has worked in the past in situations of infrequent change. Making changes like those listed above with an API interface, however, requires reprogramming or replacing both the server and the client, since those interactions are tightly coupled.

As a result, even SMBs must make some investments in architecture and infrastructure to realize the agility benefits of SOA. Indeed, they need to have sufficient capabilities for runtime management of services, registries and repositories to manage the constantly changing metadata associated with services, security and policy gateways to enforce security and corporate policy requirements, and of course, they must also make the investment in architecture. When a midsize firm is providing the services, they may or may not place the above infrastructure in-house. Small companies, in fact, will typically find a third party to host the Services. In either case, they will need the architecture -- SOA -- that provides the overall design of the implementation.

The ZapThink take

While all of these capabilities that become increasingly practical in the context of SOA, it's critical to remember that flexibility comes with a price: the management, security, metadata, and integration infrastructure that underlies the SOA implementation. Loose coupling, after all, isn't magic, and isn't easy. It requires disciplined design and a sophisticated, yet flexible infrastructure.

Many SMBs have been leveraging Web services to reduce the cost of older approaches to addressing their external integration needs. The simple addition of Web services interfaces, however, typically remain as inflexible as the API approaches that came before. Only through the application of SOA can midsize firms build and leverage loosely coupled Web services that are flexible enough to respond to ongoing change in the business environment.


This was last published in February 2006

Dig Deeper on Service-oriented architecture (SOA)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close