We should insist on tools that support good architecture and allow us to build quality systems. There is no reason why systems built today should be harder to build than they were years ago. Just because we moved to the web should not mean that we give up on good software architecture. The following is my vision for a software development architecture:
- Changing and evolving platforms are part of the world. Our architecture should not force us to rewrite our systems every time a browser changes versions.
- Business Rules are not “part” of the system; they “are” the system. We should have a rules-based architecture that allows us to completely describe how the system should function along with an implementation layer to translate those rules into the actual system.
- An architecture that requires more technologies, programming languages, or tools than any one person can master is not a good architecture. It is chaos. Fifteen years ago, all by myself, I could design a database, build the screens, create the reports, place the entire application on a 3.5” floppy disk, and install it at my client (also all by myself). An architecture that requires a large team of professionals to build a system is not a good architecture.
- When we move to a new environment, there should be a good reason. It should be faster, more functional, more scalable, more efficient, etc. New environments should not be worse than what they replace.
- The database is not irrelevant. Persistence is important. Database architecture has matured to wonderful level. To throw it all out when we are replacing it with something less stable and less functional because the current fad is to put everything in the middle tier is not rational.
- “Because everybody is doing it” is not an argument to use a technology. For decades, our industry has been led more by fads and pundits than by logic and evidence. If you want to convince me that a technology is good, give me the logic behind why this technology should be used. Then create a prototype to prove it.
- Database design is important. It is the foundation of the system. If you start with a weak foundation, the rest of the system is doomed.
- Look at what it cost to build the system with older technology. If it costs 10 times as much in the new architecture, then the new architecture is not sound.
- There is nothing magic about building for the web. It should not be an excuse to adopt an incomprehensible and massively complex set of tools.
- Building systems today should not be any more complex, harder, less capable, or less efficient than it was 10 years ago.
Imm, good piece of list. I like point 2 more than any of them (I don’t have reason out but that is the right thing) and I doubt point 3 is wise enough for big scale applications. As the system grows larger the need for a team and division of activity arises, isn’t it?
Fair enough that you want to divide activity on a large project. But that should not be justification for uneeded and unnecessary complexity. When a project requires a group of technologies to build a single screen, there is no justification for that.
Part of my perspective is that we have built a VERY liteweight technology stack. In the Dulcian BRIM world we generate 95-99% of everything. We tend to build custom generators for specific classes of business rules. All our JavaScript is in a library that core screen developers never see or deal with.
On most projects where I have not been the architect in recent years, the technology stack includes multiple technologies, programming languages, products and tools. The first screen takes 3-6 months to build and the tech stack evolves several times before it actually works (if it ever does).
That is my point.
Along with the increasing complexity of toolsets and associated approaches, everybody also wants Business Intelligence and Advanced Analysts. To have even a shot at providing that, your points #5 and #7 come into play. Yes, we can now do analysis and inferences off “unstructured” data with tools like Endeca, but most organizations really just want some basic reporting first off the data they entered. When there are no constraints in the databases, no business keys, and no mandatory columns (because it is “just” a persistence layer) it is near impossible for a BI/DW team to build anything of value in the short term. And since the development team is usually being “agile” they have little to no documentation or metadata to help. So the BI/DW team spends hours, weeks, months, profiling the data to infer the relationships and business keys in order to build out some reasonable reports and dashboards.
But then if the app changes, or really does not enforce many rules, it all falls apart.
If we could get people to think holistically and strategically at the outset of a project, maybe we could find a middle ground. Or maybe not…that would mean they actually had to assign an architect with vision in the first place.