The title of "architect" is now common within IT organizations, as the role has taken on increasing significance. The precise title varies from organization to organization — System Architect, Network Architect, Application Architect, Data Architect, Infrastructure Architect, Technical Architect, Solutions Architect — and on and on they go. The explosion of the title makes it apparent it is being used as an opportunity to give status, recognition and possibly more money to good strong performers. There is nothing wrong with this practice, but it's not going to necessarily help drive better technical solutions. Handing out a title doesn't get the work done.
Having clear architectural objectives to drive solutions can hold architects accountable for strengthening the technical landscape and building better solutions. Through the years, I have struggled with creating a simple means to articulate good architecture principles and guide architects in their approach to designing and implement solid architecture. My guidance is centered on C.A.L.M. Architecture Principles. Good architecture should calm the landscape and the unknown. There are four main principles of C.A.L.M.:
Components: Architecture should maximize the benefits of the utilizing components. Good architecture allows use of the components to shield the application, users, infrastructure or other components from each other. This allows for change and enables new technologies to come and go with less impact on the persisting components. This approach is nothing new; good technical principles of separation of the layers of technology have been around forever (as Solomon said, there is nothing new under the sun).
The art to the science is determining the right level of components. Utilizing a component approach should protect the entity (be it an application, a network, etc.) from change. Components, modules and services should also be utilized to achieve greater reuse. Several years ago I was in a discussion with the Chief Scientist at a large IT services company concerning web services. I suggested having a lot of services did not indicate success; rather having services that had a large amount of reuse was a key success factor. An organization that has defined and implemented 1,000 services with an average use of 1.3 uses per service is not as successful as an organization that has implemented 200 services and has an average use of 5.6 uses per service. While using components is the right approach; as with most things, over use can actually create a more complex and less efficient environment.
Agility: Though the term agility is overused in IT today, agility must be a guiding principle and goal of architecture. CALM architecture examines ways to set the technical build for changes, enhancements and modifications in the future. Change is inevitable; a technical solution must anticipate change and be constructed to allow for it, utilizing approaches that position for future needs and enhancements. Today's pace of change is such a driving force on businesses that architects must be focused on how to ready for change. Agility does not simply happen; it must be orchestrated into the technical solution via data design, web services, redundancy in the hardware and fail over design, component structure and other techniques. Perhaps the greatest asset to agility is the mindset of the architect in anticipating change and caring for the aspects of change that are a natural byproduct of the business environment today. A healthy sense of paranoia (I am scared to death everything will change) helps build agility into the finished product.
Leading Edge, not bleeding edge: Some years ago when a new file structure was introduced in VSAM files, I jumped on the bandwagon and designed and delivered a major R&D application utilizing this new file type. I was the expert in this new file structure and five years after the system was turned on, I was still the expert; I was the only person who had any understanding and working knowledge with it. IBM eventually discontinued the file structure and I was left maintaining this obsolete architecture. My pride in the bleeding edge technology became an albatross around my neck as my one-off application was the only application utilizing this failed file structure. I learned a lot about the file structures, but more importantly, I learned about the technology adoption curve. It takes some wisdom to determine when a technology or approach is leading edge or just not ready for primetime in the environment.
Maintainability: Maintainability (maybe due to my failure with the R&D system), is secondary only to user functionality. Every line of code, every database, every infrastructure decision, every product decision has to be supported and maintained. Often this maintenance and support has to be absorbed with no increased headcount or budget. Technology design and implementation must consider maintainability to position the organization for success. Any technology that cannot be maintained and stabilized in the environment is like buying a car when you cannot afford the insurance and gas to be able to drive it; it has to stay in the garage or it becomes a money pit. Questions concerning the organization's ability to support and maintain the new technology are a critical aspect of the architectural design. A highway bridge no one can drive on is an architectural failure. The maintainability of the new technology is an architecture component that must be balanced in any architectural decision.
Leaders need to direct and enforce the C.A.L.M. architectural principles. They must engage and question technical architects on these aspects while holding the organization accountable to componentizing the technology, building agility into technical solutions, discerning between leading edge technology and bleeding edge risks. Leaders must diligently stress and emphasize maintainability expectations throughout their organization.
Architects are struggling to quantify the guiding principles and expectations to bounce decisions against. They are searching for boundaries to frame the landscape. Let's look forward to calm waters ahead in our architectural decisions and technology.
About the author: Gerald Shields is Practice Director, Healthcare IT for The Nolan Company. Gerald has over 30 years' experience managing enterprise scale IT functions, with a focus on enabling the business through effective automation. At Aflac, he served as CIO and in senior IT management for over ten years, and is a respected thought leader and innovator in the areas of IT management systems, technology strategy, and mobile technology.