The anatomy of the virtual corporation Architecting in a world where outsourcing is becoming the rule By Glenn Kimball

May  1998

The trend these days toward creating virtual corporations, companies whose business model involves the outsourcing of business functions, presents some interesting challenges for the IT architect. Technology, business processes, and relationships are all architected a little differently in these corporations. This month, Glenn Kimball discusses the partnerships to make and the pitfalls to avoid in architecting for this new kind of company. (3,100 words)

Mail this article to a friend

Foreword
This month, I have asked my associate, Glenn Kimball, to write about his thoughts on being an IT Architect.

Over the past few years, Glenn has worked on several large systems integration projects, many of which were Web-related.

Glenn's article demonstrates how to construct the business and technology models I described in my March column. Glenn refers to this type of working arrangement as a "virtual corporation." While my column covered business and technology models in broad strokes, Glenn talks about the factors to consider when you are actually doing the work.

--Kara Kapczynski

lmost every time you do something during your working day, whether you're buying a hamburger or taking a call from a telemarketer, you establish a relationship between a business and yourself. It might be as simple as picking up your local paper or as complex as purchasing a home. Whatever the case, these relationships form the cornerstone of our economy by providing convenience and knowledge to customers.

But we seldom consider the actual machinations that go on behind the scenes to accommodate customers like ourselves.

Now, this is not to say that each of us has no exposure to a business process, but the majority of people in business today are just one part of an overall operation. Individuals tend to be masters of one domain (or business process) and are seldom masters of all domains. Even the upper echelons of management do not always have a complete understanding of all areas of their business. They generally rely on a concrete support structure to give them information; so too is it with architecture.

The virtual corporation
What is a virtual corporation?

Ask any two people and you will likely get two different answers. Ask more and you'll probably get a number of "I don't knows." Some people think of an organization with no buildings, facilities, or equipment; others think of an organization with which you will never have direct face-to-face contact.

In fact, there are many types of virtual corporation. On one side of the spectrum are organizations that may use catalogues to distribute sales information about their products but have their own manufacturing, design, sales, and marketing divisions. On the other side are organizations that only design and manage their product and leave all of the other functions to external partners (service companies or outsourcers). The level of virtuality will vary from organization to organization based upon the capacity or desire of the organization to perform different functions.

The keystone of today's virtual corporation is outsourcing, a concept that has been taken to its logical extreme, often through the use of the World Wide Web (WWW). A number of companies now almost exclusively deliver their marketing message and complete their sales cycle via computer-based means. Traditionally, many companies have worked with external organizations to support specialized human resource needs such as payroll (payment and taxation) and benefits -- 401(k) plans and insurance, for example.

What if I told you that there are organizations out there that outsource all of their functions except for management and marketing? The organizations that outsource at this level are likely to encounter all kinds of architecture issues at the business process, relationship, and technological levels.

ACME: A hypothetical virtual corporation
Say that a book seller, ACME Books Inc., has been in the book selling business for several years and is considered the premiere provider in the market. Throughout its history this company has enjoyed a stable market that supported its income needs but recently has been losing market share to a competing online book store.

To combat this problem ACME has chosen to enter into the market space of the competitive bookstore. This means selling direct to individuals. In order to support this model, ACME finds that it will have to invest in new Web technology. ACME has a customer base that ranges from Fortune 500 companies to small businesses. Given the competitive pricing of its new sales initiative, direct sales via the Web has now become one of ACME's business goals.

ACME wants to act as upper management of all phases of the business and maintain an in-house selection organization, but the company does not want to invest in editorial, shipping, direct sales, or telemarketing with the new company footprint. In fact, it doesn't want ownership of any function other than leadership and selection. Part of its solution will leverage the World Wide Web to act as the main medium of sales and marketing. And by the way, did I mention that ACME wants to access the relatively untapped global market?

Business process factors
The fundamental building blocks of an organization are its business processes and models, collectively referred to as the business architecture of the organization. Business architecture represents the collective understanding of how the business defines its operations and pursues its mission.

Several things are immediately apparent about ACME. First, it is selling to the world and therefore must disseminate information to the world. Second, in order to facilitate the marketing and sales message, and sell books, ACME must provide a medium that gives prospective buyers the ability to identify, select, and pay for one or more books. Finally, we know the areas where ACME believes it is strong: management and selection.

ACME has made itself a tall order by working toward the virtual corporation model, especially given its level of outsourcing. In order to succeed, management needs to ask a number of important questions, including:

• What processes need to be in place before domestic sales can occur? What about international sales?
• Who is responsible for the message of the organization and eventually the dissemination of this message?
• How do we view and support the customer?
• What regulatory issues exist with relation to the enterprise?
• How will funds flow into and out of the organization?
• How will the needs of internal employees be addressed by the organization?
• What systematic tool sets will be used to support the enterprise?
• What is the delivery timeline for the venture, and how does it affect the overall profitability of the organization?

Although this list is not exhaustive these questions usually fall into one of the following categories:

• Financial (accounting)
• Manufacturing (engineering, production)
• Marketing and sales
• Customer service (post sales support, issue resolution)
• Human resources (payroll, benefits)
• Regulatory (taxation, export compliance)
• Information systems (all the above)

An accomplished business architecture will focus on the optimal operations of the business while positioning the organization to achieve all of its goals. Here is a good set of rules to follow when designing the business processes of this type of organization:

• Identify early on each of the business processes to be developed and their respective relationships to other business processes. Clear identification and definition will help develop the initial relationship and technology needs of the organization.

• Focus on the traditional strengths of the organization if you can. Do what the organization does well; outsource the rest (provided there is a reasonable solution available). Consider outsourcing to a parent organization. This takes advantage of existing infrastructure with minimal incremental cost.

• Develop a centralized ownership model. Identify business owners and technology owners and establish a concrete decision and reporting structure within which to grow the organization.

• Limit the number of integration steps you are dealing with at any one time. Do not identify then attack everything in tandem. This makes for mediocrity during the development of processes, relationships, and technology.

• Create a time table. Providing a unifying set of time frames will support your partners' integration and act as a conduit for managing the expectations of the business, in terms of what and when particular features of the business (and systems) will be ready.

Relationship factors
Relationships form the next major layer of the organization. In the virtual corporation setting these relationships has even more significance than in their classical counterparts. Relationships affect all levels of the organization from both internal and external perspectives.

In business we develop relationships at three levels. The first level is internally, where the communication and interrelationships within the organization occur. Next are the relations between the organization and its external partners. Finally, there are the relationships an organization develops with its customers. Our consideration for the virtual corporation focuses on the first two levels.

Productive relationships within the organization will be characterized by clear communication within the organization and between the organization and its external partners. The following items represent a good set of rules to work by when dealing with the relationships of the virtual corporation.

• Relationships are not only built within the organization and between the organization and external partners, but even between external partners. Ensure that these relationships are defined and that coordination between partners occurs early.

• Communicate clearly to your partners (be they within or outside of the company) know who has the final say in decisions, especially when a number of them must come together to build a final solution.

• Reconcile any methodology differences between partner organizations, especially when the relationship is closely coupled. It is always best to identify these differences between partners before they are aligned together toward the same goal.

• Service providers are usually quite competitive, so soliciting RFPs (request for proposals) from such organizations should benefit from this competitive nature. An entry-level set of criteria should be developed, and service providers who make the passing grade should be interrogated thoroughly to ensure a fit with the company's business and technology framework. Competition helps achieve margin goals.

• Pay attention to the number of partners you have. Take on too many, and you risk disconnects and overruns; take on too few, and you risk your margin and innovation. Marry the strengths of a partner to its level of participation in the overall project.

• Work from the same plan. Often partners come in thinking that they are the lead for a particular portion of an effort rather than a participant in an overall effort. This model will not work effectively if there are multiple partners, and is likely to result in implementation problems at the business process or technology levels.

• Remember, once married to a service provider, an organization will have a hard time escaping the relationship. In a virtual corporation model the level of reliance on outside vendors significantly contributes to the bottom line of the organization. If you intend to develop relationships that are easily severable, identify concrete technology and process positions that allow for a delineation of responsibilities. This will ease the transition.

Technology factors
Technology is a major component of the virtual corporation model because there is generally an overriding need to transfer information within and between the organization and its partners (i.e. service providers). Access to information is also of key concern to both customers and partners. The following diagram depicts just one scenario related to the communications issues that develop in a simple purchase process:

1. The site initiates a hold on the credit card of the customer for the amount of the purchase including taxes, shipping, and handling
2. Upon verification of the hold, the site sends a request to the distributor to identify and select the books from stock
3. Once the books are pulled, the distributor notifies the site to charge the customer for the appropriate amount
4. The site submits and verifies the charge to the credit card account
5. Upon completion of the charge, the site notifies the distributor of authority to release the product
6. The site then submits a request to ship to the shipping partner

Ignoring the tools being used, the above situation represents a fairly basic scenario that most product-oriented businesses perform every day. In traditional organizations much of the communication described above would have taken place within the organization. In the virtual corporation many of these communications occur behind the scene and between distinct organizations via some sort of communications medium, such as electronic data interchange (EDI). Each communication step involves the development of interfaces to allow for the communication between the business and its partners to occur.

Technology is also a very important component when it comes to completing business processes to support the enterprise. Technology is not only the set of tools used to enable communication, it is also the tool that provides the customer experience and infrastructure behind the scenes. Architectural concerns here will center on several levels including user interface, middleware, and data while at the same time addressing overriding infrastructure needs.

An eye to the future
In many situations, it is the technologies that do not participate directly with an application that get left by the wayside. Issues such as security, replication, disaster recovery, and high availability are often deemed to be less important than parts of the application itself (interface, middleware, and data). Often this occurs at the expense of the enterprise. Of even more concern is the tendency to believe that all of these non-tier factors are easily retrofitted into any system later in life.

A technical architect must not simply deal with the design and eventual implementation of different technologies to meet the systematic needs of the business. He must provide a foundation upon which to develop the future systems needs of the business. Here are my guiding principals for a successful technical architect:

• Perform a significant amount of due diligence before selecting technology. Even though technology investments tend to have a short life span, there is no reason to avoid dealing with the issues of extensibility, reliability, and flexibility.

• Work toward a particular application tool set, but don't necessarily become married to it. Given the wealth of packages in the market that perform tasks oriented toward particular business functions, most enterprises will, one day, encounter a new application that does not fall cleanly into its established technology set. Be prepared to trailblaze if necessary. (e.g. Java is largely viewed as a cool technology of choice for Web development, but would you run your whole enterprise on it? Probably not.) Use your tools appropriately.

• Different technologies have different functions that perform best within a specific portion of the technological spectrum. An effective evaluation will easily identify (in most cases) mature technologies for each technological area.

• Look at technology holistically. When identifying technologies to be used make sure enough effort is dedicated to evaluating how the various technologies interact and how they integrate. Mitigate technology risk by working with proven tools.

• Do custom builds where you have to. Don't be turned off by custom development. Although generally more costly, custom development will get the job done when no other solution exists or when the nearest solution requires significant integration (which can be even more costly).

• Develop an understanding of your data. This will not only identify the specific data to be transferred between partners, but will also identify the owners of data and the dependencies on data within your organization.

The Web
The most recent development in our industry surrounds the World Wide Web. Many organizations have begun to use the Web as a marketing and sales medium because it represents a relatively untapped market. Organizations that pursue this model tend to produce a smaller footprint (in terms of the virtual corporation). Some perceptions and by-products of the Web should be evaluated for validity.

First, most people assume that technological complexity has increased with the introduction of the World Wide Web. In reality, the Web is just another manifestation of client/server technology. Even though the fundamental technological complexity does not increase significantly, the number of integration steps do, and the relative newness of Web technologies can cause difficulties for organizations struggling to develop expertise.

Most people assume that technological complexity has increased with the introduction of the WWW. In reality, the Web is just another manifestation of client/server technology.

Second, the relative look and feel of the Web (as compared to more classic client/server systems) has been responsible for the development of a number of boutique organizations dedicated to the design of the customer experience. This, in itself, is not fundamentally at issue, but when evaluating these types of organizations, you should look for the specific skills necessary to deliver both business and technological features.

Third, beware of organizations that claim they can implement all forms of technology as well as a number of specialty functions such as marketing and advertising. There are very few organizations out there that can accommodate this claim. The organization that does will provide such services as a concrete business offering rather than as a by-line service.

Finally, in the Web application arena there are many software organizations that focus on specific tool sets for the Web technology space but do not usually deal from an entire solution perspective. This is one of the fundamental truths that accompany the development of a new paradigm. As the public mindshare matures the tendency will be for smaller, less-capable companies to fall by the wayside. The exception to this rule may be those organizations that sell base-class frameworks and programming environments.

Be prepared
The virtual corporation represents just another phenomenon that has begun to flourish with changes in economic motivators and tool sets. Architecture within such enterprises is a funny thing. You won't find a complete architecture that is duplicated in any two independent organizations, traditional or otherwise. Given that the number of organizations that adopt this model will continue to grow, be prepared to develop your skills in a commensurate fashion. Also realize that your peers (as an architect or at least future architect) are increasing in number. Most organizations don't have just one architect (unless the organization is relatively small). Instead, the architecture mindshare tends to be distributed among a number of people.

Resources

• Previous IT Architect columns, http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#itarchitect

About the author
Glenn Kimball is a senior architect at Cambridge Technology Partners. His concentration within the company centers around data architecture and its interrelationships with the enterprise. Reach Glenn at glenn.kimball@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-05-1998/swol-05-itarchitect.html
Last modified: