How to Get Ahead in Architecture
Appropriate Infrastructure
Technology Platform has established a core technological platform for architectural deployment. By Nurturing Vendors we can take advantage of a close relationship to acquire and influence third-party technology. But we still have to use that technology in a consistent manner.
* * *
Systems developed by different teams will develop their own idioms for communicating with core resources such as databases and remote services, and for performing common tasks such as process initiation and configuration, component location and error reporting.
It is impossible to bring an existing development organisation into unanimity with respect to its use of tools, techniques, process and method. Particularly when confronted by third-party products which may themselves have large, mature (databases) and/or complex (ORB) programming interfaces, the different levels of experience, skill and exposure found in a single organisation leads to inconsistent use of low-level functionality by developers, and incidentally makes it impossible to manage the behaviour of a complex system at runtime.
Providing a minimal encapsulation of the fundamental architectural technologies makes it possible to guarantee that these technologies are used in a consistent way. In addition, specific enhancements to basic capabilities can be incorporated, and distinct technologies can be integrated with respect to configuration and runtime management.
For example, consider a native-level implementation of a naming service, such as that provided by the CORBA COS Naming Service. As it stands, this provides the fundamental properties of such a service (hierarchical naming, federation) but presents programmers with a complex API in which names and name elements are explicitly manipulated. The Java Naming and Directory Service (JNDI) encapsulates COS naming and other technologies behind a consistent interface, allowing names to be expressed across namespaces implemented in different fundamental technologies, but still exposes names and contexts directly to the programmer. A successful further encapsulation of naming has provided
Therefore:
Identify key components which should be supported by a common infrastructure. Encapsulate service access, the process environment, error and alert notification, to impose a consistent approach throughout all components and to enable runtime monitoring an control. Standardise on lower-level infrastructure (basic components, fundamental libraries).
It is unlikely to be the case that third-party infrastructure products will be available to encapsulate the exact mix of technologies you have identified as key. However, the principle of buy-where-you-can still holds – use your standard lower-level infrastructure to build the higher abstraction.
* * *
The motivation here has something in common with Lightweight Process, in that we try to make it easier for things to go right than to go wrong. An initial implementation of the infrastructure should be a deliverable from a Proof-of-Concept: the experience of developing and using this infrastructure should itself be captured and preserved (Preserve Experience). Control (which is not to say all development responsibility) of the infrastructure remains with the Core Team.
© 1998 David Harvey
Created 6 September 1998
Last updated 6 September 1998