The desire to understand modern software development best practices is the impetus behind my study of software architecture and design. Fortunately, there are many good books on the topic. Primarily, I have been using: Software Architecture in Practice, Second Edition and Microsoft Application Architecture, Second Edition (1). The former is recommended by the Software Engineering Institute (SEI) and is surprisingly accessible for a textbook. The latter is produced by Microsoft as a guide to software developers and contains practical advice on topics such as deciding on an application type, creating an architecture, and selecting a deployment strategy.
Initially, I found these topics confusing because it was difficult to pin down exact definitions of software architecture and software design. This was not because definitions were hard to come by, but because there were so many from which to choose. The authors of Software Architecture in Practice, Second Edition offer this definition of architecture:
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
Architecture refers to the high-level representation of a system that lists all major components and how they interact. System components may be organized using specific abstractions referred to as architectural styles. The following are examples of architectural styles: client/server, layering, service-oriented, and component-based (1). Software design has proven to be less confusing. It refers to the internals of the components such as “data structures, algorithms, and other implementation details” (1).
The Microsoft text notes five design principles that appear frequently in software development writings and discussions. These principles have proven to be quite useful in helping me to understand how to construct quality software. They are summarized below.
Single responsibility principle – each component or module in a system should be responsible for providing only one feature or well-defined set of features.
Don’t repeat yourself – no component or module should repeat the functionality offered by another.
Principle of least knowledge – components or modules should be ignorant of the internal workings of other components or modules in the system.
Separation of concerns – functionality in a system should be separated as cleanly as possible; for example, separating an application into presentation, business logic, and database layers.
Minimize upfront design – software design should focus on building a system that fulfills key initial requirements. As new requirements appear, new functionality may be added to the system. This design approach assumes that requirements change over time, and that not all requirements can be identified in advance. This is sort of the opposite of the waterfall model (also known as Big Design Up Front) in which one attempts to identify all possible requirements beforehand.
Considering these principles, it seems that EHR designs should incorporate the following features:
- Allow support for modules/components that control key functionalities such as reporting, workflow, security, decision support, or the user interface.
- Out of the box, EHR systems should offer a basic feature set. New functionality would be available using add-on modules.
EHR systems designed in this manner could evolve more quickly in response to user requests and clinical requirements, possibly leading to systems that are easier to implement and use.
As usability initiatives move forward, we will likely see how well many EHR products are designed. Those that obey the above principles will be easier and less costly to update. This might be the key competitive advantage that newer systems hold over their older, more entrenched competitors. The cloud, mobile, multiprocessing, and future innovations, along with user demands for better interfaces and workflow improvements, may well be the asteroid that hastens the demise of EHR dinosaurs. I wonder who will be left when the dust settles.
- Microsoft Application Architecture, Second Edition, 2009. Available at: http://msdn.microsoft.com/en-us/library/ff650706.aspx. Accessed January 20, 2012.