EDS is investigating past IT projects to learn what could have been done better under a development theory it has developed.
The services giant has not been involved deeply in architectural pattern analysis before, but is now “mining” past development projects to establish retrospectively what patterns were used, which proved successful and how any of their shortcomings can be remedied.
The concept of “solution architecture patterns” was discussed at last week’s two-monthly Worldwide Institute for Software Architecture’s New Zealand chapter meeting. This is an EDS-developed version of the theory that technology, applications, the systems that tie applications together and the business problems that create the need for the systems, can be set down as based on a limited number of patterns. These can be reused for similar problems, and used as a basis for a continuous evolution of the current architecture to deal with growth in business needs and changes in technology.
According to presenter Vijay Seetharaman, the main shortcoming of current architecture techniques is in this latter aspect, the capability of a defined pattern to grow in a non-disruptive way and be combined with other patterns to form a higher-level pattern. This is called the patterns’ “generativity”.
“Most established patterns are too generic, not generative, they do not lend themselves to structure-preserving transformations, and they are not at the heart of the enterprise,” Seetharaman says.
The definition of a pattern can be divided into four levels: technology, applications, system and business architecture patterns, says Seetharaman. At the technology level, for example are frameworks like Java 2 Enterprise Edition (J2EE) or Microsoft’s .Net, at the application level such concepts as the MVC (model-view-controller) pattern, at the system level organisational concepts like tiers and layers or pipelines, and at the business level, a specification of purpose such as “pay bills”.
Definition of the architectural pattern itself covers the “practicalities of implementation” within architectural frameworks such as Togaf from the Open Group and TAFM from the US Department of Defence, says Ramanathan, clarifying the relationship between his discipline and these better known frameworks.
The descriptions of the technology level aroused particular interest with two representatives of the ACC, grappling with the challenge of an inherited Sun iPlanet Java-based system and the inevitable onward march of Microsoft concepts. An ACC speaker addressed the recent software developers’ conference (see Accident specialist takes risk with J2EE).
No one at the meeting admitted to having tried such an integration.