If you start an architecture with a shopping list of technologies that must be used; that architecture will be compromised. However this does not mean that you start working without an appreciation of the possible, obviously you need to be aware of limitations such as constants such as the speed of light and other real constraints.
But currently I see a trend from many, both vendors and users, trying to fix round-hole problems with square-shaped blocks. Not enough time is spent on the problem definition and truly understanding the problem; your existing tools may not be sufficient and although it may feel that it is more expensive to implement something new, at times it might be cheaper in the long-term to implement something right.
Also be aware of falling into the trap of implementing a feature just because you’ve made the mistake of purchasing something that does not fit your problem definition. If you’ve been sold something that you can’t use effectively, you have a couple of option; suck it up and learn from experience or shout and holler at your vendor/partner for selling you something which is merely shelf-ware. In my experience, the latter is often ultimately pointless and simply results in the vendor promising you some other product which you put on a shelf and not use. Use the experience to move away from architecting to utilise a feature and architecting to solve a problem.
This does not mean that you simply purchase a new system/technology for every problem; governance has a role but I would suggest that governance should be applied after the initial high-level-architecture. I like to think of it like more more traditional bricks and mortar architecture; the architect relies on a whole bunch of technical people to fulfil their vision and bring it to reality. At times these technical people will tell the architect that the architect is a complete moron; sometimes the architect will agree and sometimes the architect will work with the technical teams to come up with something innovative and new.
But in general the architect does not start their design with a specific make of brick in mind. Neither should an IT architect.
Many potential problems can be avoided from the offset by taking a detailed look at the current infrastructure before architecting for the future. A number of questions need to be answered first of all. ”How are you measuring application performance across the data centre elements, especially the SAN where the critical applications and data reside? Do you actually know how your applications are performing and how you would like them to perform?” -. In most cases monitoring is done element by element (switch, server, storage), rather than by taking an end-to-end view, as the tools that come with each component can only give you visibility into their part of the infrastructure.
This multitude of tools can easily become cumbersome; have you ever had a major trouble ticket raised and the people responsible (both internal and external) start finger pointing? This is both massively inefficient and costly to the business. A holistic view of the whole infrastructure, regardless of vendor, is essential to baseline the application performance. The old adage of ‘you can’t manage what you can’t measure’ comes into play here. And be sure to look at performance rather than availability. Availability is, of course, massively important but an application can have five 9s availability and still be slow. It’s vital to know what you have currently and what to expect in the new or consolidated system, so that you can plan for the future. Horses for courses and all that…