Download EGOWS 2004: Workshop „System Architecture“

EGOWS 2004: Workshop „System Architecture“
Recipients
Participants of the EGOWS 2004 conference
Author
Date
Martin Lehmann, sd&m AG
2004-06-25
Revision history
No
1.0
Document
Date
2004-06-25
Revision
First draft of the minutes
This document is a minute document on the results of the EGOWS 2004
workshop on „System Architecture“. Please refer also to the mindmap
EGOWS2004_WorkingGroup_SystemArchitecture.mmp (or its PDF
printout, respectively).
Workshop Topics
No.
1
2
3
4
5
6
7
8
Topic
Why are we dicussing Architecture ?
Don’t we get the Architecture for free ?
"Convince Process" needed
Design Topics
Role of Java
Development Process
Usage of Off-the-shelf systems
Is there a panacea for Architecture ?
1
Topic 1
Why are we dicussing Architecture ?
The topic „System Architecture“ is important due to several reasons.
Workstation system have a long life cycle (up to 15 years), so that the
definition of a useful and stable System Architecture is important.
Currently, new workstations systems are in development, examples:
 Germany: Development of NinJo to replace the MAP system
 Hungary: Current HAWK version has reached the end of its life
cycle, new HAWK version is developed
Topic 2
Why don’t we get the System Architecture for free ?
The pure collection of ideas and features does not lead to a stable and good
architecture automatically. Good solutions for special problems might be
known already (from the experiences of the development of older/other
systems). But the glue components and the „big picture“ might be missing.
So the definition of a System Architecture does not come „for free“. Its
definition is an on-going process. "Cleaning steps" and „Refactoring“ are
needed and useful , as long as the overall architecture ideas are not violated.
Topic 3
Convince Process is needed
A "Convince Process" is needed to make sure, that people understand, why
the definition of the System Architecture is useful.
So the project teams has to convince management and developers …
 … as following an overall architecture idea might lead to delays
 … that „pure coding and hacking“ is not the solution
 … that new technologies should be used
 … that things have to start from scratch sometimes
This „Convince Process“ is successful, if one sees the benefits of the overall
Architecture. Example are the very positive experiences when doing NinJo
benchmarks: Absolutely no efforts were needed when porting NinJo release
to the Apple platform.
2
Topic 4
Design
The idea of Design Patterns has been proven. Benefits are:
 No need to invent the wheel again and again ...
 Design Patterns are very helpful for the communication: Just naming
the pattern helps to communicate effectively and one can
communicate very precise.
Examples:
 MVC („Model-View-Controller“) for GUI design
 NinJo uses PAC pattern („Presentation-Abstraction-Control“)
For the development process the so-called Template Pattern is very helpful:
A code template is defined for how components should look like. Base
classes and interfaces help to define these templates and to enforce that the
pattern is followed.
Frameworks and other generic base implementations help the developers,
too: There is then no need to care for a lot of functionality as this is
encapsulated and cared for in the generic components.
In Object-Oriented Languages the combination of inheritance and defining
interfaces has been proven. But: Inheritance might be a problem as this
implies a tight coupling between the modules.
Topic 5
Role of and Experiencies with Java
Java is proven to be a good choice for Workstation Systems:
 Portability on the most popular platforms is available for Java.
Portability issues are moved to external packages, which care for the
binding to the platform. Examples: Java Advanced Imaging (JAI),
OpenGL etc...
 One has the benefit of using utilities and lots of Open Source
packages, where it is easy to get support. The incredible richness of
libraries helps a lot, so that one does not need to start from scratch.
Comparing Java to other languages:
 Is is useful to do the implementation of core modules in C ? You
might win some speed but loose a lot of flexibility, portability etc.
 Java vs. DOT.NET: DOT.NET is still not a choice if one really
needs portability (Linux port "MONO" is not really available)
Future of Java open at the moment but available since years
 Role of SUN and Microsoft not totally clear after their deal some
weeks ago.
 Java has very strong support by IBM: IBM pushes Java and wants it
to get Open Source.
3
Topic 6
Development Process
In a large and distributed team, a Development Process has to be defined, as
„Communication is everything“.
This has several implications:
 Documentation (like Javadoc, Design documents to show the big
picture). Documents should be published and made available for
everyone in the team.
 Naming Conventions are helpful.
 Coding Standards should be defined (Java example: Book "Elements
of Java Style").
 A Architecture Core team is needed to ensure the process and the
core idea of the Architecture. Sometimes: "You need the person with
the whip"; so one how finally decides (chief architect for design
issues).
 Training Courses and Updates are helpful to distribute the
knowledge. Example: NinJo courses with slide presentations and
programming exercises.
 Change Management has to be defined: Requirements have to be
defined and written down. Feedback to the authors of requirements
is needed if new/changed requirements have huge impacts on the
architecture.
Topic 7
Usage of Off-the-shelf systems: "Write or buy" ?
Old systems difficult to maintain, especially as lot of the functionality has
been written as individual software. So the (re)usage of (commercial)
standard components might be helpful.
Moving from „reusing of Code“ to „reusing of Systems“ is an on-going
process. Commercial databases and/or application servers (like defined in
J2EE) might be worth a look.
Problems and Deficiencies of off-the-shelf systems:
 Integration with own software is not easy.
 Normally only a small amount of functionality can be reused:
Overhead is a „killer“ argument. (Example: Commercial GIS vs.
Individual Workstation)
 Commercial apps do not really fit the needs. Most of the time a
„90% solution“ is not acceptable. (Example: NinJo library for
diagrams: Commercial „Jchart“ was not sufficient so that an
individual NinJo Diagrams framework was developed)
4
Conclusion
Is there a panacea for Architecture ?
No, unfortuately, there is no silver bullet but some „Golden Rules“:
On the "Technology level":
 Create the system open and extensible
 Use abstraction
On the "Process level". Care for:
 Communication
 Training
 Experience
So it is important to have
 … the Commitment by management and developers
 … a well defined process
 … the help of standard techniques (like Design Patterns)
5