The Grid Idea
Grid computing is getting a lot of press today as the ‘next big thing’ that will impact the enterprise. It is true that grid computing exists today in several variations such as the
Seti project, but making the concept useful, practical and a ‘value add’ for the enterprise requires some significant convergence of technologies and disciplines. To date, the major
focus has been on using grid computing as offloading processing capabilities across machines and taking advantage of unused capacity. This is similar to the motivation that drove ARPANET, resulting
in today’s Internet, to route applications to machines with the capacity to run them.
Key questions emerge. While amenable to the Internet as is, can the grid concept be moved to the business landscape and more specifically to the enterprise environment? Are there forces at work
contrary to grid computing? Can the whole scope of the enterprise infrastructure be involved or only a part? Will resources be shared beyond the enterprise with partners on both the supply and
customer side? Will this be a value add part of the business? What do you need to make this happen? How far away is this from practical reality? What is the real target of grid computing in the
enterprise?
Starting out simply, what is grid computing? It is the integration of computers on a large scale to provide on-demand access to computing resources. Notice that the focus here is on the integration
of computers, not software or data. Another term often heard in the grid context is pervasive computing, computing anywhere, anytime, on demand and so on. These ‘systems’ are intended
to be transparent to the user, promote collaboration and share common standards for such things as computer languages, data access, transport and connectivity.
In short this concept finally defines the idea of a computing utility. More than a utility, it may also define a ‘marketspace’ for the barter and exchange of computing resources. The is
the position promoted by many equipment vendors today
The prime stated purpose for business use of the grid concept at this time is promotion of business collaboration. But a key issue is the awareness of business management to what the concept is,
what it can deliver and what action the business should take in preparing for this ‘utility’.
for transporting cars and trucks and both wired and wireless telephone systems. Subtler is the network of retail stores such as a chain of gas stations or 7-11 stores. They are one utility built on
another with a shared infrastructure. The latter is most likely the model for the emerging grid concept.
Grid Evolution:
While the computing grid concept had its genesis in the scientific and academic computing and is machine and connection based, the counter on the business side is the web services business
functionality view of grid computing — same concept, different focus and viewpoint. This has decided implications for IT architecture. The current trend to components is supportive of the grid
concept. The time frame for realization however is much longer than we would like. While we can connect machines and distribute computing tasks, distributing functionality is another story.
This is most evident if we look at the way package software such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) and SCM (Supply Chain Management) are evolving. From
basic back office and operations software packages these have evolved to large multi function packages. Currently they are accessible via basic API connections. These connections are becoming more
sophisticated as time moves on. With the advent of objects, class structure, components and web services these APIs have become the point of departure for re-architecting the packages into
components. The cost of such an undertaking is large as the vendors of manufacturing software discovered in the late 1990’s. What is emerging is a component view but from the API that
gradually causes the package to decompose into functional components. The picture looks like this:
The view of the world in Figure 1 is decidedly from the perspective of integration, which is concerned with connecting ever more granular and disparate modules at varying touch points and events
into a well ordered and smoothly running system. The more granular things get though the better defined must be the metadata, so progress is constantly held in check by the advancement of
standards. Progress has been made with web services standards (UDDI, WSDL, SOAP) and more recently in grid computing through the efforts of IBM and others who have developed the Open Grid Services
Architecture (OGSA) But more difficult and thorny issues will surface with the definition of standard services and documents (UBL).
At the present time vendors are providing a sort of componentized API that can access the functionality of their packages. There are varying ways to implement this idea but the simplest way is to
have an API that looks like a component and mimics a web service. Keep in mind that even though the basic request/response mechanisms supported may use web services protocols these API’s are
at their heart proprietary. This buys vendors time to restructure, re-architect and rebuild their application into functional pieces that can be sold or rented on the web for use by anyone who
reaches an agreement with them. The result might look like the diagram below.
needed to switch calls that there would be a booming demand for operators supervisors, managers etc. In the meantime, the automated switch to enable dialing directly (the stepping switch) was
invented in about 1875, not long after the telephone. So the technology existed for switching but the need was not there. Switching calls became so labor intensive that the cost of the switches was
less than the cost of operators and it became a business decision to make a technology change. Of course, the reality is more complicated but the essence serves as a good example of technology
convergent with business need. The equivalent today is the cost of development versus the purchase of a package or a component. As the cost of development goes up the attractiveness of alternatives
increases.
In this approach you construct a bill of materials, then assemble the components into an application and then execute the application. Change is accomplished by altering the bill of materials. Each
time you change the bill of materials, you are performing a different and hopefully improved process for your business. The components can be your own, purchased from someone or rented from someone
for a short time as a virtual or one time app. Clearly you need a form of production control for governance of this type of approach.
The work to get to this point is significant and many technologies and social/cultural conditions are not yet in place to enable the result.
Getting to the Business Grid
Several things must be in place for the business grid to evolve and provide substantial benefit:
First, several convergent technologies must be in place to make this happen for a business. Commercial components, connective logic, bills of material, managed metadata
and so on. These capabilities are not all at the same point of evolution. Further some are subject to co-evolution, that is, they change in pairs or triplets. IT and business cultures are not yet
to the point of change. Most of all, the burning need to change the way we do IT is just now emerging as a cost related issue.
Second, there must be a supply of standardized components that businesses can use not just hardware platforms. Much like buying parts for a car that are standard or
somewhat standard, components must exist for simple things like orders, invoices or more basic forms such as invoice line items or even more basic a redefinition of the invoice into simple grouped
components with an assembly list and build instructions.
Third, there must exist a set of ‘build instructions’ like the bill of materials in a manufacturing firm and a matching routing list that shows how the build
is accomplished. The bill of material in this case will be made up of metadata of the business. Metadata is now low on the radar of most businesses and perceived of little value. As a result there
is little in place to put together a bill of materials for an application that is standard and can be transmitted say via XML on the grid with components assembled and run according to the run
instructions.
Fourth, there must be a matching form of governance to deal with the administrative control issue of various shared, exchanged and purchased computing assets.
Fifth, there are unexplored political implications for this form of computing. If business crosses state lines the federal government may conclude it has the right to tax
transactions. There needs to be a period of legislative tolerance as is now on the web to delay the taxing piranhas looking for new sources of revenue.
Sixth, there may be considerable cultural issues with the use of a grid concept. The most severe will be on the IT staff itself; large amounts of developers will have to shift to companies that
build and market the parts or components. This is already a trend but will be accelerated as soon as the various approaches shake out. This may cause some interesting moves such as a union of
developers to protect jobs, or resistance to use of components as the impact becomes clearer. When users realize they can order an application and specify it then request it be run, there will be a
significant shift from looking to IT as the lead in computing to companies that are purveyors of application components and pre-arranged builds. This is a similar pattern to the one that swept the
auto industry in its early days. Custom built to standard parts to companies that assemble to their own perception (any color as long as it is black) and finally to market needs. As an example, we
already have companies that assemble to their own perception in the ERP, CRM and SCM spaces. They just don’t have standard components yet and are compensating temporarily through the use of
standard interfaces, like a standard mount for an engine attachment in a car.
Finally, and perhaps most important, there must exist an attitude and business model that exploits the grid or web services approach.
happened was that bandwidth grew because of the Internet, video became viable on the net and finally the culture issue caused camera picture transmission by phone to emerge on the mobile phone as
the first real business opportunity and, not in the US, but in Southeast Asia.
Conclusion
What are the prospects for the grid concept going forward? For the near future the shared use of machines will be the focus. The business functional perspective depends on the series of
contributing factors mentioned above. Each contributing factor must evolve to where it can support or enable the others needed to make the whole functional grid happen. Breakout will occur when the
group of technologies, cultural issues and business perceptions converge.
How and where the grid concept comes to fruition is still not determinable. The issues raised may seem almost to difficult to overcome, yet solutions to such large problems often come from totally
new technologies and perspectives, the so-called left field solution. The attention currently paid to this topic will serve to identify more issues and stimulate technology innovation to solve the
problems and accelerate acceptance.
If you have any ideas drop us a line.
References and Websites
References:
- Kowalkowski, Frank and Berman, Moira, “Bricks, Clicks and Mortar Turmoil”, Delphi B2B Summit, November 2000. Available from Knowledge Consultants, Inc.
- IBM, “The Era of Grid Computing”, January 2003, www.ibm.com
- Foster, Ian, “The Grid: Computing Without Bounds”, Scientific American, April 2003, pages 78-85
Websites:
- Grid Computing Info Center – www.gridcomputing.com
- Grid Technology Partners – www.gridpartners.com
- Hildebrand, Carol, “Evaluating the Concepts of Utility Computing”, CIO tips and newsletter May 21, 2003 – www.searchCIO.com
Look for the follow-on article, Exploiting the Grid: The Keys to Realizing Business Value.