Who is Systems Architect?

The Systems Architect is the high-level designer of a system to be implemented. The systems architect establishes the basic structure of the system, defining the essential core design features and elements that provide the framework for all that follows, and are the hardest to change later. The systems architect provides the engineering view of the users’ vision for what the system needs to be and do, and the paths along which it must be able to evolve, and strives to maintain the integrity of that vision as it evolves during detailed design and implementation.

Responsibilities of a Systems Architect

A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints. This article describes the myriad responsibilities of a software architect, and attempts to identify human personality traits that naturally aid a person in such position.

• An architect abstracts the complexity of a system into a manageable model that describes the essence of a system by exposing important details and significant constraints.

• An architect maintains control over the architecture lifecycle parallel to the project’s software development lifecycle. Although an architect may be most visible during the requirements and design stages of a project lifecycle, he or she must proactively monitor the adherence of the implementation to the chosen architecture during all iterations. Architecture on paper is fruitless unless implemented proficiently.

• An architect stays on course in line with the long term vision when projects’ scope creep attempts to manipulate software architecture in a certain way in order to satisfy the desires of myriad stakeholders. An architect must focus on actions that produce results early while staying on course for the long term. When project variables outside of one’s control change the architect must adjust the strategy given the resource available while maintaining the long term goal.

• An architect progressively makes critical decisions that define a specific direction for a system in terms of implementation, operations, and maintenance. The critical decisions must be faithfully made and backed up by understanding and evaluation of alternative options. These decisions usually result in tradeoffs that principally define characteristics of a system. Additionally these decisions must be well documented in a manner understood by others.

• An architect sets quantifiable objectives that encapsulate quality attributes of a system. The fitness of the architecture is measured against set marks.

• An architect works closely with executives to explain the benefits and justify the investment in software architectures. This may be done by participating in business process re-engineering activities, by using Cost Benefit Analysis Method, or by measuring the level of component / architecture re-use between projects with the help from the software process improvement team. Software architect must be effective in order to deliver results that are meaningful to the projects that have an impact on the bottom line that result in greater profits.

• An architect inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices. Educating the recipients and participants of system architecture is essential to successfully selling the chosen architectural path. Specifically the stakeholders must be able to understand, evaluate, and reason about software architecture. If an architect is the only one who can read and understand documented system architecture, then he has failed to integrate his best practices into the organizational culture.

• An architect fights entropy that threatens architect’s structural approach to problem solving. It’s an architect’s job to keep the inertia going once the project is in progress. He or she must convince all relevant stakeholders that the chosen approach is sound – moreover the chosen architectural solution must be well explained and justified. The benefits of implementing a system in a particular way must be explained not only in terms of “that’s the right pattern for this problem,” but also to demonstrate the measurable benefits – such as easier integration. For example, in a product line approach an architect must be able to demonstrate how the subsequent projects will be easier to implement due to the presence of a common base from which subsequent work can be done.

• An architect creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals. For example, a customer may demand to become more involved with a project and they may need to know an abstract view of a system on the level understood by them. A government customer may require an architect to demonstrate early in the project how a given system meets High Level Architecture requirements for a specific framework. It’s the architect’s responsibility to identify and present a sufficient level of information that a customer needs.

• An architect acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development. If the concept of software architecture is not well recognized in an organization it may be a “tough” sell to formally recognize the role of software architecture in a SDLC. Without senior management commitment and without mature software development process, architecture of the system on paper may not reflect the actual architecture of a system.

Role of a Systems Architect

Architect’s Personality and Other Traits

• An architect is a human filter that process complexities and outputs an abstract high level model of a system. Conveying the output to the stakeholders requires excellent communication skills – written, verbal, and presentational.

• An architect is a negotiator. The method of principled negotiation should be the tactic of choice for an architect. This method is most suitable in contrast to soft or hard negotiation method, because it seeks mutual cooperation between an architect and project stakeholders. An architect will be expected to deliver better, faster, and cheaper, but since only two-way combo can be selected an architect must negotiate to decide which aspects of a system will be considered first and under what conditions.

• An architect must convey a sense of credibility and trust; an architect must be perceived as successful. An architect can attain such status with his prior successful experience, formal training in the field (certifications in the future), and by his or her ability to deliver successful and relevant architectural artifacts through every stage of the SDLC.

• An architect believes in his ability to perform well. In a leadership position attitude is everything – if the passion for success is absent, then an architect must step down from the leadership pedestal.

• An architect must be patient and resilient, as the only thing constant is the change itself. Since software architecture has direct influence on the quality characteristics of a system, an architect will interact with a great number of people with a full spectrum of personalities. He or she must quickly adapt to the way stakeholders operate, as it’s not possible or feasible to expect them to speak the language of an architect.

What do you need to become a Systems Architect

First, to be considered for a Systems Architect position, it typically requires several (usually 8-10+) years of IT experience with an established reputation as an expert within a specific area. For example, many of my fellow architects have deep knowledge in at least one of more areas including security, collaboration, middleware, networking, mobile devices, governance, Service Oriented Architecture and messaging, mainframe development, open systems development, Windows development, web development, storage, database, and specific vertical business applications.

Once you have had proven success and a solid background in a few technology areas, it may be time to consider working with the broader picture for design and planning – which is why many consider the Systems Architect role.

To answer what training is best, I’d like to look at what skills are most needed:

1. Soft Skills

Probably the most overlooked and yet probably the most important skill that differentiates those that choose this path. Most companies consider the Systems Architect role as equivalent to a middle manager role and also expect the soft skills to be on par with this “peer group.” This role requires a significant amount of selling the ideas, concepts, plans, direction, and evaluations to both developers and IT people as well as to business and technology management teams.

Top soft skills to consider:

• Verbal Communication Skills. Consider courses on making and delivering presentations, becoming more influential (think sales types of courses), and any improvement in language. A good option may also be Toastmasters to allow for practice in making presentations in front of groups.
• Written Communication Skills. Start reading the documentation that is produced internally by the architecture groups. There are also many classes that can assist that range from email to full evaluation documentation and architecture drawings. See what the current group is producing today and start working on creating similar documentation for your own group or area.
• Interpersonal Communication Skills. Get an honest assessment of your own interpersonal skills and be aware of them as you work with others. Learn how to become more flexible and adjust to a given situation is extremely important. A Systems Architect has to work with a wide variety of people that include upper management, middle management, technology developers, support groups, project managers, vendors, and customers. Look for courses in areas that you feel you need some help.

2. Functional Skills

A Systems Architect role is ever changing depending on the current strategy and priorities of the company. It is important to be always in the mode of continuous learning. I usually aim for at least 2-3 new training classes or seminars every year in addition to regular reading on new technologies or architecture best practices and background. There are a few Systems Architecture and Enterprise Architecture courses or conferences that can help to provide many of the concepts shown below.

What should you read and learn

Some of the required reading or classes should include the following:

• Enterprise Architecture Frameworks. It is important to have an understanding of the main architectural frameworks which includes POSIX, TOGAF, Zachmann, DoDAF, and FEAF. Determine which one that you and your company have adopted – or more likely what variation or combination of framework.

• Architecture Diagram Examples. There is no standard format for these but an investigation of the ones internal to the organization as well as the various examples of Conceptual, Logical, and Physical diagrams. It is best to have an understanding of the differences of each of these diagrams along with various techniques for modeling dependent on the type of project and solution.

• Unified Modeling Language or UML. This will provide a background understanding and good foundation for many diagrams and documentation. UML is a method of defining an abstract or complex solution using a standardized visual model.

• Business Strategy Development. Understand the current strategies, how they were developed, and who developed them. Understand the impact based upon business, applications, and infrastructure.

• Technology Lifecycle and Evaluation. Evaluation of current and new technologies and products and their lifecycle to include emerging technologies to retired technologies. This includes making choices of when to introduce these new technologies and when they should be replaced.

• Architecture Principles and Policies. Architecture decisions need to be made based upon a common direction. Review your company’s or other company’s written principles and policies.

• Governance and Policies. This will depend on your given vertical marketplace but include different organizations such as SOX or ISO.

• Vendor Management. Related classes could include ethics and legal courses in addition to understanding how to develop Request for Information and Request for Proposals.

• Project Management. Many Systems Architects may also be required to lead the technology portion of a project.

Who is Right for the Architect Role?

Some personality tendencies that I personally have identified are as follows. Ask your self do you posses these attributes:

• Builders – these are people who are most gratified when “building”, whether it be building a network from scratch or a program from scratch we get bored easily with the same work day to day. We typically build, and move on, build, move on.

• Problem Solver – do people come to you when they have a problem? If you are able to take a very complex and substantial problem and break it down into meaningful “bites” to craft a solution, you are a problem solver.

• Effective Communication – SAs rely heavily on communication. We translate “business” language to “technology” language.

• Technology Generalists – remember Architects don’t typically roll up their sleeves and actually do the programming, although the ones who have programmed in the past gain the respect of their programming team members much easier. An Architect will typically have multiple lead developers reporting up to them in a project environment. So, don’t get TOO good and any one thing (other than building and problem solving!). Architects are typically generalists that draw on a broad range of expertise.

Why We Need Architects

Experience tells us that without having someone (or a team, for larger projects) responsible for the architecture, the architecture is no-one’s priority, and it gives way to what is on the priority plate—features that need to be released soon!

My Advice

It’s hard to say what’s the exact formula to be on top of the IT stack but here is my advice.

• Work in higher visibility IT roles; director level or above. This is where you learn your political savvy, your understanding of using IT to address business challenges, and hone your communication.

• Sign up for project work. Serve as Project Manager or development lead on high visibility / high impact projects. When you are working on a project, you are essentially engaging in implementing a solution to a problem. Get a PMP certification if you can.

• Stay current in technology. A year might as well be a century in IT. Always stay current on technology, its use, different methodologies, approaches, etc.
• Try to get a job in an organization that is known for its technical human resource typically a large IT consulting firm.

There I said it all. Wish you all the luck in your career and remember always work what you love and have fun in your work or else your life will end up stagnant and monotonous with no urge to grow.

Adnan Arif

I almost cringe sometimes when strangers outside of the IT industry ask me “What do you do?” Typically one of two reactions occur – eyes glazing over with an “oh” or “what type of buildings do you design?” I’ve come up with some interesting different answers to the question ranging from “helping to design computer systems/networks” to “working with internet research” (which is much more glamorous/sexy and easy to say but not really the whole truth). I’d be interested in any good ways you’ve found to respond.

I also get asked the question from those within the IT industry and even other Systems Architects themselves which often leads to a more interesting and dynamic discussion of where a Systems Architect starts, where it overlaps, and where it ends.
The Webster definition for an architect is a person who designs and guides a plan or undertaking.

A good list of detailed responsibilities for a Systems Architect is also found at Wikipedia which is more focused on a person who has control of the big picture and overall requirements for a complex system ensuring a robust, cost effective, reliable, and strategic solution.

“The systems architect is the high-level designer of a system to be implemented. The systems architect establishes the basic structure of the system, defining the essential core design features and elements that provide the framework for all that follows, and are the hardest to change later. The systems architect provides the engineering view of the users’ vision for what the system needs to be and do, and the paths along which it must be able to evolve, and strives to maintain the integrity of that vision as it evolves during detailed design and implementation.”

A Systems Architect usually has the following responsibilities:

• Overall design – the blueprints which provide the map
• High level planning for the development – overall steps for creation of the solution from the blueprints
• Integration constraints – rules and constraints for all components going into the solution
• Adherence to standards whenever possible – to maximize the future investment value and minimizing costs
• Customization for individual customer needs – understanding and recommending the best customization based upon the customer’s needs (which include anticipation of their needs and explaining it in layman terms).

This illustration will summarize the role of a Systems Architect.

Role of a Systems Architect

My own definition is also dependent on the scope of the Architect – enterprise, for a particular business or vertical market focus, or within a specific project. The Architect will have more granular responsibilities as the scope gets tighter and the designs therefore more detailed.

Probably I should add on to my title that I design computer based systems the same way an architect builds a house – my “computer house” needs to be built with standard switches and electrical outlets for future expansion, custom features to be desirable and marketable, and cost effective to meet their budget.

Adnan Arif