Featured Article
10 Reasons You Need an IT Architect
Every IT organization needs skilled architects who are experienced in designing systems, databases, networks and user interfaces. In this article I'll give you 10 reasons.
1. Architecture is critically important to IT.
Let’s start with a definition. In my book, Boiling the IT Frog, I explain the IT use of the word “architecture” this way:
|
|
For a building like a house or a skyscraper, the word “architecture” refers to the way that building materials are assembled to form a structure. Similarly, the architecture of an information system refers to the way that software and hardware components are assembled to form the overall system. Just as building architecture has styles, IT architecture has different styles for system construction. Just as building architecture has building codes and best practices to ensure the safety and longevity of a building, IT architecture has system standards and best practices to ensure the security and longevity of a system. And just as building architecture has approaches which make the maintenance and alteration of a building easier and less expensive, IT architecture has approaches which make the maintenance and alteration of software easier and less expensive. |
|
The book then talks about architecture’s critical importance:
|
|
The architecture part of the IT strategy is often omitted, but this omission is a huge mistake. Would you want someone to build a new city without a plan for where the streets should go or how the buildings should look? An IT strategy without an architecture definition is similar — systems would be developed without regard for how they will fit together or even how they should be built to minimize ongoing cost. In an IT organization without an architecture, it’s not uncommon to do the equivalent of adding two additional floors to a building which has a foundation that wasn’t designed to support the extra floors. |
|
2. The IT architect focuses on how to do things, while the CIO focuses on working with the business to determine what to do.
As I said in my book, the most common IT mistakes are doing the wrong things – not doing things wrong. The CIO has to concentrate on figuring out what to do, but someone else has to figure out how to do those things. That’s the architect’s responsibility.
3. In companies with centralized IT, the IT architect must manage the architecture approach being used by each IT project. One of the biggest advantages of centralized IT is the efficiency gained by using common approaches and standards. The architect makes that efficiency possible.
4. In companies with decentralized IT, the IT architect must coordinate the architecture approaches being used by the individual decentralized IT organizations. Even in decentralized IT, there is a need to share data and information across the various parts of the company, to present a unified view of the company to customers and employees, and to maximize the sharing of effort being expended by each decentralized IT organization. Decentralization doesn’t imply anarchy, and even in companies which have decentralized total control of IT, someone should facilitate sharing of architectural information across those decentralized IT organizations.
5. In a company which uses off-the-shelf packaged software like ERP or CRM, or software-as-a-service applications like those from Salesforce.com, the IT architect has to figure out a way to sew together all of the different disparate systems so that they can talk to each other. In an ideal world (I wish I saw this more), the architect would also be involved in the decision to buy a particular off-the-shelf packaged software solution, so that the solution could be evaluated based on the difficulty of integrating it with the company’s existing systems.
6. In a company environment where business people make systems decisions based on articles in airline magazines, the IT architect has to clean up the mess made by the poor system choices. This is sort of like the Winston "the Wolf" Wolfe character played by Harvey Keitel in the movie Pulp Fiction – someone who comes in after major mistakes have been made and tries to sanitize the situation to prevent future issues. Only in this case the mess has to do with software that doesn’t play well with others, packages which require non-standard hardware and operating systems, and the need to customize software to present a consistent user interface to customers and employees.
7. In an international company, the IT architect has to deal with the software implications of internationalization. The architect must figure out how the company’s systems are going to deal with multiple currencies, multiple languages, multiple laws and legal systems, and multiple cultures. The architect must also determine how data will be converted between various combinations of systems. Internationalization is one of the most difficult challenges facing an architect, kind of like building a skyscraper that has to change appearance and behavior based on who's looking at it.
8. The IT architect has to separate truth from fiction in the latest round of buzzword architectures (e.g., Agile, RAD, RUP, SOA). In this role the architect has to be the gatekeeper and voice of reality: Does a particular architecture or software development approach get tested or used in your company? Which buzzwords should be ignored? Which improvement claims are real?
9. The IT architect has to figure out how to phase in and integrate the latest technology that your company chooses to adopt. These are technologies like RFID, VPN’s, security tokens, encrypted disk drives, smartphones and PDA's. Are they viable? What pilot tests have to be done before they're used in production? How will they fit with current technology?
10. The IT architect has to anticipate change. The only constant in IT is change. Business needs will change, customers will change, technologies will change, legal requirements will change. The biggest challenge for an architect is not to pick the best architecture for current needs – the biggest challenge is to pick the best architecture for constantly changing future needs, and to revise that definition of “best” on an ongoing basis.
Conclusion
In the Q&A session after a recent webinar, I was asked to describe the working relationship between the CIO and the architect. I cited reason #2 above, and said that if the CIO is focused on what the business needs, then the Chief Architect is in a sense serving the role of the “Chief How Officer.” That in a nutshell is what the architect does, and that's the difference between a CIO and an architect: the CIO determines what to do, and the architect determines how to do it.
If you have a CIO but not an architect, then the CIO will be less effective in setting business direction for IT because the CIO will be distracted by how issues. It is also quite likely that a CIO in such a situation will either be a good CIO or a good architect but not both. That's because the personalities and skill sets of the two roles are so different.
The bottom line is that both a CIO and an architect are needed, and they both make a major contribution to IT strategy – each in their own way. Good IT architecture is critical to successful IT, and you can't have good architecture without good architects.
Note: I've used the singular form of the word "architect" in this article, but obviously in larger companies there can and should be many architects. In such an organization there is a need for a Chief Architect who provides overall architectural direction. This person is also sometimes called the Chief Technology Officer (CTO) to distinguish the job from the CIO who is more business focused.
Permalink
You might also be interested in these related newsletter articles:
- "How to Become a CIO," from December, 2005, describes the 8 qualifications of a CIO
- "How to Fail as a CIO," from March, 2007, describes ways that CIO's fail, and provides advice on how to prevent those failures
- "The Information Technology Merry-Go-Round," from June, 2005, talks about centralization and decentralization of IT
- "Web Services aren't the Answer...but use them anyway," from August, 2003 (four years ago!), describes web services and why you should use them
Harwell Thrasher is an author, speaker, and advisor specializing in the human side of Information Technology. Harwell shows IT and business people how to work together more effectively by taking the magic out of IT. Call Harwell at (770) 331-6979, or see more on the web site at www.makingITclear.com.
Send comments or questions to newsletter@makingITclear.com.
|
del.ico.us 
Digg this 
Reddit 
Slashdot 