Business Object Design and Implementation Workshop
Business Object Design and Implementation Workshop
Position Paper The Architecture
Reference Model
William Hertha
(bhertha@mtnlake.com)
Organization
Received: 24 Oct 95
In our work, we have found that our business colleagues express their needs, discuss their strategies, formulate their objectives, and then state the need for new processes to support these goals, and new systems to make their processes more effective.
Without knowing exactly what it means, there is a call for an "Architected Solution." In trying to respond to the plea, we have found that the architectures offered through standards organizations, vendors and others frequently focus only on a very small part of the problem--the infrastructure.
Although OMG, through its various Special Interest Groups, are looking at defining "application" level architectures, there does not seem to be one architecture that ties together the goals, strategies, requirements expressed by the business, with Business Processes, Business Components, and the Technical Infrastructure.
Our work attempts to bring together these notions, into one reference model -- a sort of meta architecture .
As a starting point, we can view the Reference Model as a way to manage all the information that an architect is subjected to.
The Reference Model organizes information into four main categories:
Business Strategies are the statements the business makes about its goals, and objectives. Generally we capture these in the form of Business Requirements and Events.
Business Processes are the implementation of the Business Strategies in the form of work flows.
Business Components support the Business Processes by automating parts or all of a Business Process.
Infrastructure is the underlying technical platform upon which the Business Components execute. At the top, infrastructure includes the middleware necessary to provide independence of the physical location and environment in which the Business Components operate. At the bottom, is the actual hardware base.
As depicted above, each category is a grouping of relevant "components." In the Reference Model, only the types of components are shown, while in the actual Business Architecture, specific components would be identified. For example, the Business Process category might include processes for selling a product, while the Business Component category may contain an Address Component.
The question then arises, how does one identify the proper set of components? The answer varies according the to category. For the Technical Infrastructure Category, we can look to industry and standards organizations for support. For example, IBM's Open Blueprint, OMG's CORBA, and Microsoft's COM/OLE. When we move up to the Business Components category, we find no standards, but we do see work going on in OMG.
Therefore, key to the success of the Reference Model will be its ability to incorporate new standards as they emerge so as to identify a proper set of components.
Components are however only one aspect of an architecture. The dynamics of the architecture must also be captured--the way components are configured together to solve a problem. To that end we incorporate patterns and frameworks, and like components, they exist in each of the categories of the reference model. These provide standard designs/configurations to specific problems. Frequently there may be several alternatives, each offering a different trade-off on performance and cost. By cataloguing this information with the architecture developers have a mechanism to go back to their business partner and explain the issues they face, the trade-off available, thus including the partner in the decision making process.
If we look at each category, we can see that each one implies a different skill: the Business Strategy requires those with strong business and strategic skill; the Business Process category requires those with business process engineering skills; the Business Component requires those with business development skills; and the Technical Infrastructure requires those with strong technical skills.
Looking at the linkage between the adjacent categories we can see a "What/How" relationship. For example, the Business Strategy states "what" is needed, relative to the Business Processes category, while the implemented business processes state "how" the strategies are implemented.
Frequently we face a problem with communications between people working in different categories. The source of the difficulty frequently stems from two sources: a lack of understanding; an unclear understanding of what is possible.. As our catalogue of components grow, they start to form a language, enabling better communications resolving the first source the of communications problem.
Secondly, the growing catalogue also shows a "higher level" category what is already available and thus what is possible, and at what cost, risk, etc.
The Reference Model is not limited to business architectures. The same concepts applied to other domains, such as development. Like business, there are development strategies, and goals. There are development processes, and there are development components. There is the business of development.
The ability to use the same reference model as a basis for both a business and development architecture allows a single organization to track the evolution of a developed component (i.e., some business component) from conception through to "death." We can manage it in development, through testing and deployment. We can monitor it in production; feed it more resources or starve it as required. We can retire it, when it reaches the end of it's useful life.
It allows an organization to show shared categories, such as shared Technical Infrastructure.
We are continuing our work on this model, and are presently populating the reference model with components for our business architecture. We look forward to the day when we can refer to the OMG's list of business components.
| Page Hits | |
|---|---|
| This Page | |
| Since 10/25/95 | |
Top