In my opinion, there is a lot of incorrect information being floated in vendor advertisements about what are being called "open systems." I believe some vendors are claiming their systems are open in a way that is both inaccurate and misleading.
The key to sorting out fact from fiction about open systems is to have an understanding of the elements of system architecture.
Architecture has three major components:
* Platform: what the system runs on. This is the hardware and operating system.
* Development Environment: how the system is built. This includes the processes and tools used to construct, test, and maintain the system, and to manage the code and development projects. It also includes the database management system (DBMS).
* Applications Design: how the system was designed. This encompasses the overall design and structure, the major pieces and how they fit together, and especially how the system allows flexibility
Lots of vendors claim to be open, but they are really only addressing one or two facets of architecture- usually the platform and/or the development environment. While these are important, they are not nearly as critical as the applications design. Yet, this area is neglected in vendor marketing material.
Platform. This, as noted above, includes the hardware and operating system. Key platform architecture considerations include performance, reliability, and viability (will the vendor be around in a few years). There are lots of options, but two major contenders in the hardware and operating portion of the platform architecture are Windows on Intel (Wintel) and Unix. Both are market mainstream, which is a plus, because market-mainstream products tend to not disappear from the market.
The Wintel platform is less expensive but it is also less reliable. Our IBM RS/6000 system has been running since June 2002 with only a single unscheduled outage, and that was caused by human error. We were formerly on a Wintel Platform, and we experienced regular systems crashes (probably at the rate of once per month). Additionally, we had to reboot the system nightly.
Development Environment. When considering development environments, some vendors get hung up on the programming language and DBMS. That is a focus on tools, but it neglects other important aspects, such as development process. There is an old adage that says, "a fool with a tool is still a fool."
Tools. Tools include not only programming languages, but also include other key things like testing tools, configuration management tools, project management tools, and the like. The newest and best programming languages cannot overcome a poor development process, including lack of tools to support that process.
Processes. My experience has been that tools themselves are far less important than the processes and how development is managed. A good development environment is much more than a programming language. It includes things like requirements management, project management, configuration management, and quality management.
DBMS. Many claims of openness are focused on the database. On the database management systems (DBMS) side, there are relational and hierarchical databases. SQL Server, DB2, and Oracle are prime examples of the former. While relational technology is newer, it is not necessarily always better. Each type of DBMS has strengths and weaknesses, so it depends on what you need to do from a business perspective. In a hierarchical DBMS, the relationships between the various records or tables are "hard coded." This results in a great performance.
In a relational DBMS, the relationships are not fixed. They must be established at run-time. This produces more flexibility in certain circumstances, but the cost is in performance, and at times, a degree of added complexity. The key issue is what you need the system to do. The hierarchical model works very well for financial services organizations, especially credit unions. One final thought. A database can be too open. You really don't want people writing directly to the database bypassing the security and integrity controls that are, or should be, part of the system.
Applications Design. This is the real key to system openness. It encompasses the whole design of the system in general, and how it allows flexibility in particular. Getting to a really great applications architecture is very hard to do. Very few designers are capable of creating really great designs. A really great design is loaded with designed-in flexibility.It has, for example, a very large number of parameters in place of hard-coded functionality. It also includes flexibility-enhancing tools to extend the system's functionality, and thus allow rapid response to changing business needs. Some of the best applications design I have seen in three different industries were not built with the newest technologies, but they nonetheless were the most responsive to the needs of the businesses they support.
So what about vendor claims of openness, and why do I think they are inaccurate?
First, I would say that many vendors have an incomplete and very narrow view of architecture. When I look at advertisements, I see vendors focusing on the database management system, Wintel platform, and programming languages.
Second, new technology is not automatically open. While there may be some advantages in some cases to certain newer technologies, the simple fact is that any technology, new or old, can be used to build either an open or a closed system.
Third, the most critical test of openness is how well and how fast a system can respond to business needs.
Bill Burrows CEO of EECU, Ft. Worth, Texas.
