What Does an IT Architect Do?

This is an interesting question for anyone thinking about working as an Architect but also for anyone else working in IT because there isn't a consistent set of definitions regarding architects within the industry. Architects who do more or less the same things with the same skills could variously be referred to as:

• Enterprise Architects
• Solution Architects
• Project Architects
• IT Architects
• Technical Architects
• Data Architects
• Application Architects
• Business Architects
• Cloud or SOA Architects
• Security Architects

There are many types of architects, yet they all share certain characteristics...

And the list goes on. What if anything differentiates these roles (1)? More importantly, what elements do these roles have in common (2), if any? Not too long ago in the history of IT, few people used the term Architect to describe anyone. Why has this changed (3) – we've gone from no architects to more than a dozen flavors in perhaps 15 or so years?

Let’s answer some of these questions:

1. The Architecture roles (listed above) are generally differentiated by some level of solution specific expertise in one area or another. This could involve methodology, toolsets, skillsets or even industry domain knowledge.
2. An Architect is not or at least should not be tied to one specific element of expertise – if he or she is focused in only one area then they become a Subject Matter Expert (SME) and not an Architect. This is an important and practical distinction because technology keeps changing – today’s stack will not be the same as tomorrows’. Architects must understand the entire stack as it evolves and change skill sets as that evolution occurs. All Architects are designers. All Architects are problem solvers. All Architects are by nature also systems and business analysts. 
3. The genesis of the Architecture role in IT is directly related to the rapid decentralization and added complexities associated with the PC and Client Server revolution (and everything else that has occurred since then). In other words, as IT environments and systems became more complex, it was apparent that a “complexity manager” was required. That person is the Architect. 

Why would we necessarily refer to a complexity manager as an Architect? The metaphor as designer is obvious – but just as important is the idea that the Architect is the one who has the vision and understanding to see how all of the various pieces ought to fit together. An Architect, in either realm is by nature also an integrator.

So, how does an IT Architect differ from a traditional Architect (the folks who design blueprints for buildings)? Perhaps the most interesting difference between the two roles is that there is often an expectation within IT that the Architect or Designer is also the Builder. In the world of brick and mortar construction, it is very rare to see builders follow a career path from hanging drywall and pouring foundations to drafting the design for the entire building. Yet, in Information Technology it is relatively common to see developers become architects.

There is a good reason why this happens in IT but there is also a problematic result as well. The reasons why it happens are because:

1. the architecture career path is still unclear and we have to get Architects from somewhere and 
2. unlike with buildings, Architects in IT need to understand more of the technology associated with what gets built. 

We need that understanding because IT is much more dynamic than building design – we ‘reinvent’ our industry about every 5 to 10 years now. Some people still consider Frank Lloyd Wright’s work to be cutting edge and he’s been dead for more than 50 years – clearly IT and traditional architecture move at a different pace.

The problematic outcome of this situation is that many Architects tend to view the design and analytic processes associated with architecture to be inferior to ‘just building something’. This viewpoint more or less contradicts the true mission of what Architecture is supposed to do and the problem that it solves. In other words, Architecture has arisen to manage complexity; yet rapid build with minimal analysis is the number one culprit behind increasing complexity in the first place. This type of Architect could be referred to as an Architect in name only because it generally implies that they would not be practicing many of the key attributes associated with Architecture. This also potentially opens up a larger debate regarding Agile versus non-Agile IT, and that debate will never go away. The important takeaway from that debate though is when you reach the systems of system level; architecture becomes increasingly important.

Contrary to popular belief, Architecture and Agile Methodology actually complement one another.

There is a another consideration in understanding the role of the IT architect as well – without industry standard expectations in relation to what the Architect role actually represents – there can be wild inconsistencies across or even within organizations that utilize architects.  So, how could we solve this dilemma? Here are some suggestions:

1. Develop an industry standard set of role descriptions for IT Architecture. (there are groups that have developed standards for Enterprise Architects, but that is entirely too narrow to handle the larger set of expectations associated with IT architecture).
2. Ensure that any Architect in any role, anywhere – is given the top level training or expectations that are common across all architecture first (before drilling down). 
3. Help foster the distinctions between lead developers, tech leads, SMEs and Architects. This will help organizations determine when they really need an Architect as opposed to one of the other roles. If the roles are mixed it is highly likely that one part or the other of the combined role is going to get shortchanged – and that could lead to a number of unforeseen consequences. 

There are several other key attributes that help to distinguish IT Architects from other roles in IT; these include:

• Architects are often asked to act as liaison between other solution stakeholders. Sometimes Architects even become the official solution advocates.
• While sometimes asked to be advocates, Architects also tend to be the key resource in determining when a solution needs to be dropped. An Architect must be impartial when making such decisions.  
• Architects are complexity experts or managers – in other words typically Architects are dealing with “Systems of Systems” scenarios. Thus, the Architect has to be concerned not just with how the solution will operate in its own context, but how it will function in the context of the larger ecosystem. 
• Architects act as honest brokers in being able to question assumptions and drive change in order to mitigate potential risks. While other roles may be involved in this; typically Architects have the best vantage point to deal with it.
• Architects are change agents – more-so than any other IT role. Architects are asked to either envision or evaluate new technology and lead the move towards it.

The IT Architect is a relatively new role; it is often interpreted differently but it is uniquely positioned to become ever more important. As this role continues to help evolve the IT landscape, it too will evolve.


Copyright 2013,  Stephen Lahanas

#Semantech

Read More

What's in a Name ? - "Enterprise Architect"

Enterprise Architecture is a new discipline within the Information Technology domain. Few if any university level programs adequately address the skills required to work as an EA. Perhaps sometime soon there will be degree programs focused on enterprise architecture – perhaps not. The vast majority of people who work in the field as EAs are self-taught and often work in other IT disciplines as well. All Enterprise Architects began their careers doing something else.

Enterprise Architecture also represents the apex of technical positions within IT – both in terms of career status and usually in terms of compensation. It represents an alternative to management as an ultimate career goal (e.g. the inevitable interview question – where do you see yourself in 5 to 10 years). It serves this capacity because it allows IT professionals the opportunity to apply their expertise and experience in high profile roles that often are responsible for leading critical enterprise projects.

What is somewhat confusing is the fact that enterprise architects aren’t always referred to as such or may be shifted back and forth between enterprise and project roles. It is helpful to view architecture within its continuum – that continuum is separated mainly by scale or scope:

• Level 1 – Technology Specific Architect (many to 1 – project or enterprise)
• Level 2 – Solution or Project Architect (many to 1 enterprise)
• Level 3 – Enterprise Architect (may be more than 1 per enterprise based on domain responsibilities with a Chief Architect as lead).

Other roles that are sometimes asked to perform EA tasks include:

• Systems Analyst
• Business Analyst
• Data Analyst
• Systems or Chief Engineer

So that begs the question – what types of tasks is an Enterprise Architect asked to do? Here is a brief list (by no means meant to be comprehensive):

• Determine enterprise workflow models.
• Perform enterprise technology and architecture assessments.
• Create EA views using one or more EA Frameworks (ToGAF, DoDAF, Zachman etc.)
• Provide Transformation Blueprints (ERP, SOA etc.)
• Create Enterprise level Ontologies, Taxonomies or Master Data Frameworks.
• Determine Data Center Configurations and Processes.
• Design Network Architectures
• Design Data Architectures
• Design Application and Service Architectures
• Solve Problems
• Integrate multiple architectures / technologies
• Design products and services

The technologies and tools change. Often, the exact nature of the role changes as some aspects of the work are shifted to specialists (can be solution or technology architects) or as new disruptive technologies or challenges require attention. The Enterprise Architect is the first line of defense against complacency and the number one agent or facilitator of change in any organization.

An architecture assessment methodology, like the one above, can be applied to any technology...

The EA is a technologist, first and foremost and must necessarily spend much of their time understanding and learning new technologies. The EA must also never lose sight of the realities involved with actual implementation of higher level strategic designs and directives. It is perfectly reasonably and highly recommended that from time to time the EA should take more specialized roles to make sure they don’t lose touch with the difficult details associated with real world projects. The EA is a generalist who has the ability to be a specialist in any number of areas (and in fact probably was before moving to EA).

The enterprise architect is someone who is comfortable extending their boundaries – pushing the envelope. If you’re the type of person who doesn’t like constant change or challenge than enterprise architecture is the wrong career path. An EA is someone who doesn’t assume they always have the right answer – but is dedicated to finding it regardless of the difficulty involved.

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

What does an Enterprise Architect Do?

The first thing most people think when they hear the title “Enterprise Architect” is that this person does some sort or modeling or design activity. Architecture is and always has been a visual medium and in some sense that initial metaphor which connects IT architecture and brick and mortar architects remains valid. Most EA’s need to know something about design – whether it be in the context of a specific design tool or paradigm or just the ability to visually depict complex topics in an intuitive manner. What is important to keep in mind though is that there is no one “right way” to model or design and that these visualization activities represent only a portion of what the enterprise architect does within a typical engagement or project.

There are many who might disagree with the “right way” comment – some of those people may feel that a particular EA framework or perhaps UML is the one preferred way that work should be prepared. To some extent, UML has achieved a universal status of sorts and can be used within most other EA frameworks; however there are some things UML is still not good at representing. For example, high level Domain models and Use Case diagrams convey relatively little information yet there can be richer depictions of operational concepts at a high level (what is generally described as an OV-1 in DoDAF or ModAF or perhaps a BRM in FEAF). There will always be room for flexibility in the way that information can be presented visually and then the question becomes how important is it to capture aspects of the information being presented in a data driven tool. The secondary question might be whether a non-standard visualization is meant for one or more audiences. Often times what is useful for business stakeholders may not be helpful to developers who need more specific design notation to support application development.

Most EA artifacts begin w/ taxonomies - this one was used to develop a DoDAF TV-1

Now we come to one of the truly vexing aspects of working as an Enterprise Architect – each organization is going to view things slightly differently. There will be different opinions about role, process and deliverables from one engagement to the next. This may even be the case within a single organization but is certainly the case when crossing from one organization to another. What this imposes on the EA is the need to understand or be fluent in multiple different approaches and to be capable of developing new ones as needed. This was one of the reasons we made a point within the EA Manifesto of stating that the tools or products don’t drive Architecture, they merely support it. One of the main responsibilities associated with Enterprise Architecture is the ability to tailor tools to unique organizational expectations and still allow both to function properly.

Yet all this is still only part of a bigger picture. The EA is not merely expected to be able to model or design in different tools using different modeling paradigms – we’re also expected to:

• Understand all or most of the technologies involved (in a project, in a domain or across the whole enterprise).
• Be able to help develop, assess or implement strategic objectives or initiatives. These sometimes extend beyond pure technology-based capabilities.
• Be able to estimate scope, cost or schedule for initiatives or parts thereof.
• Be able to support functional and technical requirements gathering and validation.
• Be able guide product evaluation processes.
• Be able to evaluate new technologies in a less formal sense and project future impacts.

And the list goes on. The EA is not an executive position although on occasion EAs are also asked to provide various types of leadership, such as:

1. Solution Evangelism
2. Industry Thought Leadership (1 and 2 often work in tandem)
3. Oversight of specific projects
4. Tech Oversight of the enterprise

As you can see, it’s difficult with all of these types of expectations for an enterprise architect to become specialized in any one area – in fact if he or she did it would likely reduce their effectiveness in the role quite a bit. So, in answer to the title question, what an EA does is whatever the customer asks them to do at any one given time – keeping in mind all of the other expectations that relate to the immediate need and the role. EA is often viewed as entirely strategic, but the reality is that it is a pragmatic mix of strategic goals and tactical needs. This balance can be met if one side doesn’t give way entirely to the other. For example an EA that never becomes involved in the day to day operational issues of an organization may find themselves hopelessly out of touch after some time and the relative value of their strategic contributions would likely decrease proportionately.

Copyright 2012, Semantech Inc. All rights Reserved

Read More