The Extensible Architecture Challenge – Part 1
Context: Requirements for an extensible architecture
Introduction
Developing software that perfectly fits the needs of different clients is impossible. However it is possible to build a software architecture that is composed of many small pieces that can be stitched together for a single client to serve its needs. I’m going to write a series of posts that show one possible way to build such an architecture.
Known Requirements
By now I came up with a list of these technical user stories:
- As an integrator (e.g. a company that uses the system), I want to be able to access all system functionality via a REST based API, so that I can integrate it into my existing application landscape easily.
- As a user, I want to have a web based user interface to all system functionality, so that I can access the system from everywhere.
- As an operations guy, I want the backend tier (database + business logic) to reside on a different machine than the frontend, so that I can put a nice firewall in between.
- As a system integrator, I want to be able to leverage data from existing systems, so that users don’t have to enter the same data in more than one system.
- As a system integrator, I want to configure the systems functionality individually for each client, so that it fits the clients needs.
- As a developer, I want it to be very convenitend to extend the data, the behavior, and the look and feel of the system, so that I can shape it to the customers needs.
- As a user, I want the system to show only the data that I require for my processes, so that I don’t have to maintain information that I don’t really care about.
@Robert: Waiting for your comments
Advertisement