A multi-layered approach to on-demand computing
Kenneth Tingey
August 27, 2004; Updated September 20, 2006; February 7, 2008
Onions have layers. The outside layer protects it from the elements. Each subsequent layer has an organic purpose that enables the onion to be healthy and strong. Like onions, organizations have layers, especially where large-scale issues are concerned. For an organization to prosper, each layer must fulfill its purpose in terms of contributing to the overall objectives of the enterprise. To coalesce the multi-level resources of the enterprise – especially the knowledge of the organization's experts – a high degree of teamwork is required. Such teamwork involves people with many kinds of skills and unique orientations.
In principle, teamwork is useful terminology for an enterprise. However, in reality, teamwork is difficult to implement as the infrastructure of an enterprise is generally oriented toward an individualistic paradigm. To move toward a more layered approach where teamwork might thrive, it must be apparent to the people within the enterprise that the enterprise is serious about coalescing its resources to support a multi-layered enterprise. Without such clarification, lines get blurred between layers, productivity decreases, tempers flare, and the "grand design" suffers. Moreover, computing power is not efficiently directed at the key processes of the organization and the mission of the enterprise suffers. With a workable means of tapping raw processing power in the service of the organization and its primary mission, the promise of "on-demand computing" and "dual control" can be met.
Various models have been developed in management and in technology to describe the challenges inherent to managing an organization. Every organization has at least an implicit organizational chart. Furthermore, technology-driven structures, such as OSI and other layered models, are based on critical technical considerations. Two important elements have surfaced in our research into the interaction between organizations and their computerized systems. In order to achieve the kind of functional integration required to perform at the highest levels, “immersion” defines how comfortable an organization is in being computerized, while “fluidity” determines the degree to which they are able to convert their knowledge and activity to and from computers. The layered model is designed to help to achieve high levels of immersion, while calling attention to critical fluidity issues.
This model is an amalgamation of enterprise as well as technology layered approaches. It is considered as a means of helping the governors and managers of an organization to make sense of their computing infrastructures, that they better support the mission of the organization. As more and more of what enterprises do is computerized, system implementation is increasingly critical to that mission.
The questions of "who does what" and "who should do what" are of critical importance. Such decisions are not always made by those in position to know based on education, experience, and training what the real requirements are. Fundamentally, the question is one of assisting managers to make managerial decision and technologists to make technology decisions – without having either set of decisions obstruct or limit the other. Fortunately, with standards-based developments spurred on by the Open Systems movement over the last decade or more, many alternatives exist from a technology standpoint (the bottom layers in the graphic, from the black to the brown categories). The real challenge is in logic management in the center of the model through the yellow to the green and blue layers – branching down to the orange data layer when data is needed.
The point of the layered model is to identify the kind of issue at hand in a system development project prior to moving forward. The ideal set of solutions would be that which would provide stability, processing power, and "back door" security (to be discussed in the yellow section) without constricting the business model and the principal operating people of the organization. Even better, the general interest would be met with tools that actually enhanced thought processes of principals and subject matter experts as they developed computerized processes. This is key to achieving “fluidity” in an enterprise system. More attention needs to be drawn toward providing classification, taxonomy, and process manager tools to the business managers and experts of an organization so that they can directly express their decision models by means of the system. In the 1960s, Sorter argued for such a structure based on accounting theory, but the objective has yet to be met.
Prior to solving a problem or dealing with a system implementation issue, all parties should come to agreement as to what kind of issue it is. CEOs should typically not make "black” level decisions, purchasing processors and devices – particularly not based on a relationship at the “country club.” Furthermore, data management personnel should not be allowed to dictate the business logic of the firm – a task that should be reserved for managers that have dedicated their careers to management and have bloodied themselves in the battles of the market or in gaining specific expertise in the subject matter at hand.
On aircraft carriers in the United States Navy, flight deck personnel's uniforms are color-coded to eliminate confusion in the heat of the battle. Similarly, in the very challenging process of developing enterprise system capabilities, clarity is a critical element leading to success of the project, though often missing.