Architecture & Change
Whilst writing a reply to Tom's comments on a recent post, I realized that my thoughts might make more sense as a post than a comment:
I think Tom hit on something that a lot of us spend a lot of time arguing about, but rarely articulate explicitly and clearly in our posts, articles, whitepapers and books - the importance of architecting systems properly. I'm not going to attempt to indicate how we should architect our systems, nor am I going to propose the nature of a given architecture at this time.
What I do want to comment on is the absolute need for sound architectural principles and practice, especially as we begin to move into the realms of building Service Oriented systems that integrate multiple previously-disparate platforms and technologies. The advent of the SO wave of concepts and the technologies that enable us to build these systems in no way obviates the need to carefully architect, design and build our future systems.
Without a sound architecture that takes into consideration the needs of the end users, the available technology and infrastructure and the capabilities of the system's builders, it's unlikely that a system will be a success. How many times have we all seen apps that look fantastic, but perform poorly, or systems that are fast and relable as heck, but unusable and monsters to maintain and update?Good, clean, sound architecture is the core of a successful system which involves as much art as science. This is a hard-won discipline which isn't found as often as one would like and when it is found, it's often overdone to the most extraordinary degree.
And this latter point is very important - it's essential to balance the need to carefully architect a solution with the need to actually deliver what the users and consumers of the system need in a timely and cost-effective manner. Unless you absolutely HAVE to, there is typically little point in spending 2/3/5/10 years working on an entire detailed enterprise architecture prior to building it, which might then take another 2/3/5/10 years. By doing this, one ends up building the system using tools, techniques and processes which are, by the time the system is complete, often horribly out of date and more costly to maintain than if an iterative approach was adopted from the outset. And, of course, the systems we build often no longer meed the needs of the business which has often changed considerably since the project was architected.
We as a species seem afraid by the notion of change and yet it's change that often excites us the most and it's when "times are a changin'" that we tend to excel. Why then are we, as architects, designers, developers, testers, managers and operators of IT systems so afraid of change? Why do we continue to fear change rather than embrace it? Why do we continue to spend far too long designing systems assuming that the world around us will remain the same to then hold up our hands in horror when we realize that everything has changed ... again?!
Why don't we start with the mindset that everything is going to change and that nothing will stand still? Why don't we design our systems so that they can change and that we expect that they will? Why don't we adopt a more iterative approach to designing and building systems rather than trying to repeatedly boil the ocean with our processes and practices?
It's my fervent belief that this is the mindset that will lead us to design systems very differently in the future - especially since we stand at the dawn of a new age of systems and technologies that will enable us to be far more productive and dynamic than ever before. Let's throw down the conservative, staid, slow, cumbersome procedures and practices, tools and technologies of old, and embrace the following:
- You just never know what's going to happen in the future so don't aim too far ahead
- Deal with what you know to be true today
- Assess what's coming down the tracks in the near future
- Plan to adopt the cream of the crop
- Don't assume the world stands still - believe that things will change
- Architect, Design and plan appropriately
Thoughts?
