A recurring theme for me lately has been the ubiquity of what I'll call the "horizontal issues" that effect software systems. In particular servers, but most of these issues effect all software designs. While I want to focus on the architecture part of software for now, there is a similar commonality at the next level up as well: the business level. Maybe I'll get to those some day.
I call these issues "horizontal" because if you were trying to draw them in a block diagram, they tend to be drawn horizontally. The application logic tends to be drawn vertically as "higher level" subsystems.
So let's jump in with a non-exhaustive, unordered list:
- Installation
- Licensing
- Configuration
- Logging
- Performance Monitoring
- Data Management (user files, databases, etc.)
- Alarms (User Notifications)
- Authentication
- Access Control
- Auditing
- User Management
- Administrative Control (User Roles)
- Clustering & Load Balancing
- High Availability (HA)
- Sign Up
- Billing
- Customization (themes, plugins, scripts, etc.)
- Upgrades (installs, user data, configuration, customizations).
- Testing Interfaces and Harness
As you can probably tell, each of these can be a massive effort. The problem is that for most software, few if any of them are optional. Most complex systems need something in each of these areas. Since these are not the core business concerns, however, they get minimal attention in favor of focusing on the "important" parts.
When you move from prototype/demo to a production system, you neglect these at your peril. While your users may not spend most of their time in these areas, many of them must be navigated before the "real work" can get started. The care and feeding of your software will also require that users interact with these various subsystems. The last thing you want is for the core competence of your software to be masked by user frustrations in these areas.
Implementing robust solutions to all of the above would be a massive development effort in its own right. So how can we as software engineers solve all these problems and still keep our project on schedule?
I'll start on that next time.
2 comments:
Think about upgrades in an HA environment, where the user of the system doesn't see any downtime. Upgrades can fail and you need to provide ways to back them out, potentially including reverting schema changes to the data layer.
You've just proved that any problem can be made harder by actually trying to solve it ;) I hope someone comes up with an approachable solution for this problem before I retire!
Post a Comment