System design, while still a very young field and not physical in nature, needs to be more like architecting a physical structure than it is today. In that, it needs to come closer to adhereing to a set of principles and rules that can be generic enough in nature to apply to almost any project, without limiting flexibility and change. Given the competing natures of the two different endeavors -building a physical structure and building an abstract system – these rules cannot be the same, though there might be overlap.
First let’s get the definitions down.
Design Standards – A set of mandatory rules that the design process must take into account. Design standards are typically a set of mandates that an organization stipulates that must be applied to any solution architecture.
Best Practices -A set of commonly held and accepted methods or techniques for designing solutions. As the name suggests, these method and techniques are proven to be successful over many iterations. This applies to not just the design phase, but design, construction, testing, delivery and support. These evolve over time, and are pratices that have been found to be consistent and nature and successful in implementation.
Design Characteristics – Elements or components of a given design.
Design Principles – A collection of fundamental propositions that serve as the basis for a design paradigm. These are typically industry accepted guidelines for solving specific problems. Much like Best Practices, principles develop over time, but are instead always applied to the design process.
Design Pattern – Is a typical repeatable solution for a common problem.
Design Paradigm – A set of rules that define the approach to a given design, usually made up by a set of design principles.
Without examples definitions don’t make a lot of sense.
A design standard example would be a requirement from the EA team, that all deployed web based applications must have fail over capabilities.
A best practice example would be; Before any coding gets underway, a formal document must be delivered detailing all of the requirements of the project.
A design characteristic example would be; The system was designed with many reusable components.
A design principle example would be; The solution will be distributed.
A design pattern example would be; An Iterator Pattern, provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. (Wikipedia) Another common example of a design pattern is the Model View Controller pattern. In this pattern the system is broken up into a View layer responsible for showing data and interacting with the user, the Model layer which contains all the business logic and interfaces with the database, and the Controller layer which interfaces between the two and directs view direction.
A Design Paradigm example would be; Object Oriented Design – which provides a set of rules governing the practice of solving common problems, encompassing many design principles.
Over the next series of blog entries I am going to explore the world of SOA design principles and concepts, using the definitions provided above and explain how they are used to design a well thought out SOA architectures, given the understanding that each enterprise is different and therefore will have it’s own set of rules governing SOA implementations.
I promise in those entries to use well thought out ideas from over 16 years of designing and implementing solutions, in both a SOA and non-SOA environments, to simply explain how one can go about designing a SOA architeture, while meeting some of the most common business criteria, and ultimately provide the customer exactly what they require.
*To give credit where credit is due, one of the main resouces for this post is http://whatissoa.com.
