|
Grid Computing and the Enterprise: Myth or Reality
Published: October 1, 2003
Published in TDAN.com October 2003
The Grid IdeaGrid 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’.
Examples of the Utility Concept
There are many examples of the utility concept. Clearly an electric utility delivers power to a subscriber regardless of source or destination. The same is true of gas pipelines, highway systems
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:
Figure 1. The Package Component View Today
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.
A Cost Driven Convergent Technologies Example
A simple analogy to show this idea is the advent of the dial telephone. Early in the 20th century the job to have was that of telephone operator. The reasoning was that so many operators were
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.
Figure 2. The View 10 Years Out
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 GridSeveral 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.
The Picture Phone
The picture phone was viable in 1965. It consumed considerable percentage of the available bandwidth and people were concerned about being visible at times that might be embarrassing. What really
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.
ConclusionWhat 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:
Websites:
Look for the follow-on article, Exploiting the Grid: The Keys to Realizing Business Value. Go to Current Issue | Go to Issue Archive
Frank Kowalkowski -
Frank is President of Knowledge Consultants Inc., a professional services firm founded in 1984. He has 30 years of management consulting and industry experience in manufacturing, distribution, insurance and financial services and the public sector. He is the author of a 1996 book on Enterprise Analysis (Prentice - Hall) and over fifty papers.
Clyde Laakso -
Clyde is President of Lake, Vesta, and Bright Consulting Group, Inc., a professional services firm established in 1998 specializing in management reporting and data warehousing. He has over 20 years experience in management and technical roles. |