As IT has matured as both a discipline and an area of employment, the focus on skills and knowledge continues to shift away from pure technology and the nuts-and-bolts of infrastructure design, implementation and management. IT’s role has evolved from a pure, tactical cost center to a nexus of strategic investment and an opportunity for organizations to develop competitive advantages.
Nowhere is this more apparent than in the IT architect’s organizational role. An IT architect is an individual who not only understands multiple aspects of information technology from a technical and development or implementation perspective, but who also understands how the proper application and use of IT can help an organization or company meet its goals, improve productivity or profitability and, in general, help organizations work more effectively. Thus, an IT architect brings an understanding of and appreciation for business or organizational needs, goals and objectives, and can assess the value of information technology investments in terms of the returns they bring and the opportunities they enable.
Any study of the IT architect’s roles and responsibilities reveals a profound and major division between two areas of activity: IT infrastructure and software development. IT architects are active in both areas, but those who concentrate on IT infrastructure tend to be more involved in specifying, designing, implementing, testing and driving maintenance of systems, networks and other aspects of IT infrastructure. Those who concentrate on software development tend to be more involved in specifying, designing, implementing, testing, releasing and driving maintenance of either semi-custom or custom software. Of course, there is much in common between the two job roles in terms of the kinds of people likely to wear the IT architect’s hat, and also in terms of the soft skills they must have at their disposal to succeed in the role. But there is a big difference between the subject matters involved, and in the kinds of technical skills and knowledge IT architects must bring into IT infrastructure positions as opposed to software development ones.
IT Architects in the Workplace
As examples of this type of job role, a hypothetical case will help illustrate each side of the divide. Bob is an IT infrastructure architect for a large state university. For the past three years, his job has been to evaluate various line-of-business systems that the university uses, and to make recommendations for new and better ways to upgrade the institution’s IT infrastructure to support current and anticipated needs and demands. Thus, he’s found himself involved in:
- Upgrading the campus backbone to a dual gigabit Ethernet structure, and investigating future upgrades to prepare for the next bandwidth jump.
- Implementing a campus-wide storage area network that permits business and academic departments to access network storage as if it were local, and to assist these organizations in assessing and establishing current storage requirements and future storage needs.
- Implementing a new campus-wide two-factor authentication system that uses thumbprint scans and tokens built into employee ID cards to manage access.
Bob has had to persuade department heads to allocate funds and personnel for these projects. He also has had to meet repeatedly with university executives to propose projects, develop detailed plans and budgets, and report on progress and problems over a three-year period.
The nature of the work requires not only strong technical acumen, but also the ability to explain and justify technical needs and solutions to non-technical audiences, and to be at home navigating the sometimes-murky pools of departmental politics. Because many of the people who report to Bob for these projects do so either temporarily or only part-time, he’s also had to develop strong people skills to keep his reports aware of and informed about their assignments, progress and priorities, and work to keep them plugged into their “real jobs,” while also making sure that their bosses don’t feel left out. In short, Bob is responsible for a delicate balancing act that requires equal parts communication, persuasion and the ability to inspire enthusiasm and commitment in others at all levels in the university.
Sally, on the other hand, is an 18-year veteran of the software development side of IT. Prior to taking on an architect’s job two years ago, she’d been a project manager on several successful projects. She works for a chemical company that performs continuous processes on various petrochemical-related feedstocks. Her development project is one that aims to permit the company’s chemists and chemical engineers to turn the models of new processes and feedstocks they’re always developing into automated systems that can drive the procurement of the raw materials necessary to drive those processes, and to work with chemical plant systems to specify, monitor and manage their operation.
Sally’s work started with a 12-month pilot project during which she worked with department heads at the plant involved in operations, engineering, procurement and production and delivery. Working with a team of technical specialists, she developed a set of specifications for a new software system that would integrate with existing plant equipment by the end of 2006. Her plan also involved running this new system parallel with the current one for six months (three months shadowing the old system, three more months with the old system shadowing the new one, with the new one assuming control for the first time).
Along the way, Sally’s team had to select a development environment (Visual Studio .NET with the .NET 1.1 framework, along with a migration plan to Visual Studio 2005 and the .NET 2.0 framework in the first quarter of 2006), specify a set of interlocking programs to meet departmental needs and put a team of programmers to work building the new system. Because of the scope of work involved, Sally also had to oversee the hiring of two national consulting companies and coordinate their efforts with an in-house programming staff that would participate in the development and testing phases of the project, eventually assuming full responsibility for its maintenance and upkeep.
Like Bob, Sally found herself enmeshed in departmental rivalries, but her task was further complicated by the “us versus them” perceptions so typical when outside personnel are brought in to help meet aggressive timetables or add additional resources without requiring increases in permanent head-count. As Bob did, Sally had to propose, persuade and eventually inform executive staff at the chemical plant about her activities, and to provide regular status reports and financial projections about the project. Unlike Bob, she found herself working as a de facto department head because of the large number of people and the sizable seven-figure budget she had to manage to meet project milestones and delivery goals. But the same set of leadership, communications and interpersonal skills that Bob needed to do his job served Sally in good stead as well.
Developing Skills and Knowledge
Those not already familiar with the balancing act that walking a project manager’s tightrope can entail may be wondering how you can develop these skills. Those who’ve already walked in these shoes, even if only for a small distance, already know that they come, in part, from study and practice, but also from careful observation and cultivation of opportunities on the job.
It’s a testament to the importance of the IT architect’s job and its contributions that you also can find various professional organizations that focus in this area. There also is a growing number of certifications that support this job role, as well as those th