Idea of software design patterns was inspired by architectural design patterns.  We look at more time-proofed engineering branches and take what is best and proven, and that is good. But many software companies still create software like it would be sufficient to make some  sketches and then let developers do the work. This may work in case of small systems that are not going to be the core business domain support systems. In other cases there will be workarounds, patches and limitations all around. And it may work somehow (not optimal, not efficiently – just somehow), and client may and probably won’t care what’s underneath.

I like building IT systems, and I like cars.  If you buy a car, most of the people don’t care about the details of mechanisms such as clutch or differential. Why would they? But the role of mechanical engineer in the process is to make sure that the car won’t stop in the middle of the road on every second trip.

Business also often does not care if quality metrics are good for the system under development. They have their business goals, they want the software that will allow them to make every day business better, more efficient, cheaper, more reliable, etc. But the goal is to create software so that it will not require to be rewritten partially or completely every second trip, pardon, I mean delivery.

So when you build a house you hire an architect that designs the house.  Architects also provide other services, like construction site control, sometime a construction site manager is hired. When you build a house and don’t have the knowledge about how it should be build won’t ask someone who does to check if everything is the way it should be? Sometimes one does not do that – and then the roof is leaking, pipes are freezing.

Building software also requires plans and control otherwise it will turn into a big ball of mud. Been there, it’s not a nice thing to see. IT needs architects that will watch over the technical aspects of software. They can be called lead developers or otherwise, but important thing is that they:

  • Create architecture for the project with solution or enterprise architects
  • Create project standards or choose standards from the set of company standards
  • Startup the project at technical level (e.g. at a meeting)
  • Make sure that the architecture if being followed in development (some aspects can be automated)
  • Make sure that standards are applied (quality metrics automation and manual reviews)

If architect has also a team leader role than he has to coach the team on making high quality software.

The thing is – if you buy a car you know that it is a sedan, and you cannot expect it to become a station wagon. In software business always wants to add new features, so the design has to be extensible on architecture level, it has to be scalable, secure, testable (allow maintainable test automation), manageable and reliable.

The other thing is that software architecture evolves, so some must be there with the wide knowledge about the system to design and control this changes. Other wise we get back to big ball of mud. Interesting thing is that some of this concepts are present in architectural engineering.

This does not mean that budget for creating this software will increase two time or something like this. You can control the level of control and automation and use appropriate methods and tools that will provide the most benefit. I’m a big fan of Domain Driven Design, as provides us with many proven rules on designing and building the software. In DDD we have a concept of domains, most import is Core Domain. When making a system in this domain we would profit from assigning best staff, strict control process. I’m not mentioning Continuous Integration as it is a must from my experience to create a efficient development pipeline. We can go event further and do Continuous Deliver – but this depends on the system under development.

I will discuss these subjects in details in next posts, with examples of tools like Structure101, Dependomenter, Tattletale, Sonagraph and quality metrics (ISO/IEC 9126, ISO/IEC 25010:2011), software delivery process (including CI) and Domain Driven Design

Have a nice day ! 🙂