By E.G.Nadhan, HP Enterprise Services
Not far from where The Open Group Conference was held in San Francisco this week is the Winchester Mystery House, once the personal residence of Sarah Winchester, widow of the gun magnate William Wirt Winchester. It took 38 years to build this house. Extensions and modifications were primarily based on a localized requirement du jour. Today, the house has several functional abnormalities that have no practical explanation.
To build a house right, you need a blueprint that details what is to be built, where, why and how based on the home owner’s requirements (including cost). As the story goes, Sarah Winchester’s priorities were different. However, if we don’t follow this systematic approach as enterprise architects, we are likely to land up with some Winchester IT houses as well.
Or, have we already? Enterprises are always tempted to address the immediate problem at hand with surprisingly short timelines. Frequent implementations of sporadic, tactical additions evolve to a Winchester Architecture. Right or wrong, Sarah Winchester did this by choice. If enterprises of today land up with such architectures, it can only by chance and not by choice.
So, here are my tips to architect by choice rather than chance:
- Establish your principles: Fundamental architectural principles must be in place that serve as a rock solid foundation upon which architectures are based. These principles are based on generic, common-sense tenets that are refined to apply specifically to your enterprise.
- Install solid governance: The appropriate level of architectural governance must be in place with the participation from the stakeholders concerned. This governance must be exercised, keeping these architectural principles in context.
- Ensure business alignment: After establishing the architectural vision, Enterprise Architecture must lead in with a clear definition of the over-arching business architecture which defines the manner in which the other architectural layers are realized. Aligning business to IT is one of the primary responsibilities of an enterprise architect.
- Plan for continuous evaluation: Enterprise Architecture is never really done. There are constant triggers (internal and external) for implementing improvements and extensions. Consumer behavior, market trends and technological evolution can trigger aftershocks within the foundational concepts that the architecture is based upon.
- Standardize: All that said, enterprises must be agile in order to react to such demands. A standardized and modularized approach is key. Standardization can be implemented in various shapes and forms. It could be the Architectural Development Method (TOGAF), the reference architecture for a Service Oriented Approach or the manner in which infrastructure services are provisioned across SOA and Cloud solutions.
Thus, it is interesting that The Open Group conference was miles away from the Winchester House. By choice, I would expect enterprise architects to go to The Open Group Conference. By chance, if you do happen by the Winchester House and are able to relate it to your Enterprise Architecture, please follow the tips above to architect by choice, and not by chance.
If you have instances where you have seen the Winchester pattern, do let me know by commenting here or following me on Twitter @NadhanAtHP.
This blog post was originally posted on HP’s Transforming IT Blog.
HP Distinguished Technologist, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. Twitter handle @NadhanAtHP.
A great post, E.G.
I’m delighted to see that you’ve noted a key point that’s been missed by many others who’ve used this example: namely, that _this was an architecture that was well matched to the client’s requirements_. The client’s apparent belief was that she would die if the house was ever finished: and with an income equivalent to tens of thousands of dollars per day, she afford to indulge that belief. (It wasn’t that it took 38 years for the house to be built, but more that work only stopped when she died, because the reason for the endless building and rebuilding ended with her death.) So in a sense, bizarre as it may at first seem, this ‘non-architecture’ was actually a very good architecture, _for this client_ – and the fact that it wouldn’t be so good for almost anyone else is perhaps beside the point? 🙂
Perhaps a closer example would be some of the English ‘country houses’ such as Canons Ashby http://en.wikipedia.org/wiki/Canons_Ashby_House or Brympton d’Evercy http://en.wikipedia.org/wiki/Brympton_d%27Evercy , which have accumulated often-incompatible architectures almost at random over the centuries. Another example would be the Dutch tradition of the ‘good-year farmhouse’: every time the farmer had a good year, he would add another room to the house – much like companies acquire IT-systems with each new merger or acquisition.
Nice to read your post. Alignment between IT and business must be kept in mind. Do it in a pre-drawn territory, but has to be agile when facing varied needs. Obviously, EA should be able to control inflated changes.
InChina, some failed projects are generally caused by the lack of governance, big gap between technical and business, lack of milestone, checkpoints and not ready for world widely accepted methodologies.
Thaks, Tom. Love your analogy about the Dutch tradition of the “good-year farmhouse”. This is so true about acquisiton of new IT systems!
Great Point, Jianqun. It is all about business-IT alignment.
Comments are closed.