Continuity
As illustrated by the millennium bug, systems perseverance often defy human expectations, as if continuity was a self-acquired characteristic of systems once set free from their unknowing designers. Hence the benefit of keeping the focus on primary issues regarding software artifacts, development processes, and enterprise architecture.
Software Artifacts
As for any engineering activity, software engineering must be clear about its end products as well as intermediate ones. If methodologies and technologies are set aside, three types of artifacts should be considered:
- Requirements provide the necessary starting point. How they are expressed will essentially depend on the languages familiar to users.
- Models are introduced as intermediate products when the continuity of processes cannot be achieved and some communication is necessary.
- Software components are the end products.
Model based engineering approaches provide a comprehensive and consistent framework for the analysis of engineering problems and the choice of development solutions.
Enterprise Architecture
Software artifacts are the building blocks of information systems whose aims is to support enterprise objectives. Hence the need of a shared framework for enterprise (business), systems (applications), and platforms (technology) concerns. As attempts to force all problems and solutions into a single formalism have been inconclusive (to say the least), on should instead maintain the separation of concerns and build a bridge between those that must be kept aligned.
Agile Processes
While enterprise architectures are meant to deal with stable and shared assets and mechanisms, business processes are supposed to deal with changes and to take advantage of opportunities. Hence the conundrum when the latter are to be supported by the former; that’s the challenge taken on by agile approaches. While that may be an easy task for low-hanging fruits of well circumscribed projects, innovative solutions are needed if agile principles are to be “scaled” up to architecture level.
Further Reading
- Models in Driving Seats
- Agile vs Waterfall: Right vs Left Brain ?
- Agile & Models
- From Processes to Services
- MDA & EA: Is The Tail Wagging The Dog ?
- Enterprise Architectures & Separation of Concerns
The resilience of legacy applications is bewildering, no doubt about that. One possible reason is while problems were not very different from today, they had to be solved with computers hundreds of thousands less powerful. Since no tinkering would have done that, programs had to be designed on sound and robust architectures. Conclusion: one should always look for core issues behind trendy ones.
Don’t you think that systems perseverance, even if surprising, was not intentional? Even though that the self-acquired characteristics are because how the AAA artifacts we defined and designed? Could it happen that some of those self-acquired characteristics be undesirable?