Derhackler’s Blog

Context: Sharpening the requirements for an extensible architecture

In my last post I described a set of requirements for an extensible architecture of a software system. As Robert mentioned, I was not very precise in what kind of system I had in mind. So these requirements wouldn’t be particularly useful for e.g. a computer game.

The system I talk about falls into the category of “enterprise information systems”. An example would be a bug tracking application, a requirements management tool or a project planning system. Characteristics of such systems include:

• It’s very data driven. Users care about the information they can manage. Most of the functionality is about how business data is produced, organized, interrelated, and presented. Users care much more about the “what” than the “how”. They want (or have to) to manage business information – functions such as “modify”, “import”, “create new”, etc. are just necessities.
• Users hate switching applications or even worse enter the same information several times into several systems. E.g. if there already is an application in place that contains address information of vendors (maybe an Excel Sheet on a network share), users would be annoyed if they would have to enter the same information into another system that requires a vendor list.
• The system has to be very responsive but not necessarily fast. Users don’t rapidly enter massive amount of information, nor are very complex operations common.
• The data that a user wants to work with at a given time is dependent on his/her current task and the role he or she is in. Users don’t want to handle or even see data that is not relevant for their task at hand. E.g. given a list of vendors, an accountant may want to see the account numbers, while a procurement persons is more interested in the total spend of this vendor.
• Users want the system to adapt to their information architecture and processes. Not only the data can be different from client to client but also the processes that govern the production and consumption of this data.
• An enterprise system does not typically have a massive number of users and the amount of data that needs to be handled is relatively low compared to large web applications.
• Enterprise systems are often very interlinked with other enterprise systems. Data needs to be maintained in several systems concurrently and synchronization is often manually.
• Security requirements are very high – data is often available only for few users and processes govern very strictly who should be able to read or modify which data.