I’ve been tangled up on many occasions in methodology terminology discussions this week with various clients, and decided that it might be appropriate to share some thoughts on clarifications on the subject.  How boring you say?  It’s time for an article to shed light on the differences between a process, approach, methodology and a framework.

Recently I was asked that if a person was already acting in the role of a software integrator, did they really need to learn how to be an Architect.  The answer was a little bit complicated, but it was an emphatic “yes!”

While the basis or core skills of a great IT architect does come from solid software integration knowledge and practice, the basic practices, approaches and thought processes as well as ways of thinking in the correct context is what is taught during an IT Architecture workshop.  Various approaches and ways of thinking allows an IT Architect to get a new perspective of the various contexts they must review before choosing a solution or constructing an architecture.

There are various thoughts on how one becomes an IT Architect, and granted there are so many ways to get here, the result is the same.  In order to become good or even excellent, the Architect takes on a different mind set.  There are various perspectives that are reviewed, and as well, various options with respect to ways about thinking about the issue, problem or opportunity are reviewed.

The architect considers more than fitting two pieces of software together, and the approach learned in a workshop will take them through the business objectives and IT Enterprise objectives, through to the various decision making techniques and options for formulating a solution.  Typically the instructions given to an integrator are taken after an architect has determined the best approach and seen best fit for the components that are selected.

During these exercises, the architect takes on a different approach with respect to requirements analysis, solution review, as well as some softer skills to deal with the political and communication parts of the equation.  Often integrators are given something very specific to be done, as well as a roadmap for doing so.  The architect takes part or creates that roadmap, and many more variables are considered than may be actually visible to the integrator.

Finally – there are various approaches that an architect learns to getting from A to B.  They learn to view a solution from a multitude of angles, and those which will enable them to see their way to the minimal path of risk.  In part, the approaches are part of the culture of the organization for which they must have an appreciation for, as well as a component of the overal IT & Business Strategies.

Hopefully that sheds a bit of light on the benefits of learning to become an IT Architect, rather than skipping these important steps.  For more information on training, see our site.

Happy Architecting.

I’m emerging from the haze of planning for my upcoming Architect Boot Camp classes.  My focus is editing my book, and between questions about “which course do I take” and “am I suited to be an architect”, I figured I’d write a series of posts related to the Architect’s Role.

The Architect’s Role

Problems are well less defined for an architect and they must spend the time to ensure that a context has been set before they go about assessing their problem.  They must ensure that the scope and the boundaries of the problem are very well defined.  The primary activity of the architect is to focus on the implications of the organizations objectives on technical choices. They must understand all of the over-arching dynamics and impacts in making such choices, as well as  leading a team of developers, integrators and implementers in the prescribed certain path.

The architect must contain and sustain an overall system view at all times while designing a solution.   The architect builds models of the problem and the solution space and must possess a very analytical and conceptual mind in order to visualize how the pieces may fit.   They must also have a strong ability to recognize patterns and apply things and concepts that they’ve known from their past when they approach new solutions.

Architects explore alternative approaches to almost every solution that is presented to them. They must view and take into account all of the different aspects within the organization such as people, process and technology, as well as technology, data, and applications when determining which approach they will take.  Architects spend a great deal of their time preparing documents, positions, presentations and diagrams, and they must be very strong in communication skills as well as their diagramming and documentation skills.

They must be very good modelers and able to adapt to varying levels of tools and be able to quickly pick up the skills required in order to use these tools readily.   Architects must have a strong business sense, and the ability to scale down or tailor up explanations of architecture to sponsors and stake holders as well as technical staff.  As you see, they must be able to describe things at very detailed levels for technology staff and implementers as well at the highest granular level for the business in order to demonstrate that they understand the business problem.

Success for an architect depends on skills and characteristics that are not typically emphasized in university curricula or on the job training.   An architect gains experience during their years within information technology.  They merge experience they may have gained from other careers and depends on their experience and their keen business sense in order to propose solutions.  They diagram &  document their solutions, and solve the largest and most complex technology problems for the organization.

More on the specific types of architects another day.

Have thoughts on this post?  Drop me a comment.

Happy Architecting!