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.

To define methodology, we are talking about a detailed and structured approach, containing both generic and tool
related step-by-step guidelines, to develop, upgrade, update improve or replace an architecture, model or system.  Methodologies are often called blueprints.  Essentially a methodology is the “cookbook” or handbook used to achieve
a goal or task for some component of information technology.
For example, the methodology container for the Project Management Institute (PMI) is called the PMBOK, or Project
Management Book of Knowledge.  Within it, are step by step guidelines to managing a project.   One should note that a
methodology, such as the PMBOK, or the Rational Unified Process identifies ALL the things you might want to do for
your project, and not necessarily dictate that every one of them is completed. Think of it as an a-la-carte menu.
Now why should you care about all of this?  Well, you’ve got architectures you want to document, and you need a
consistent manner and method in which to complete these documents and models.  I am not suggesting you make one up, but rather to evaluate your environment and select and adopt the one most appropriate for you within your culture.
In a previous life, I spent all kinds of consulting time taking the Rational Unified Processes into businesses and help clients tailor the RUP into their own methodology or Systems Development Life Cycle.  Essentially I chose the items from the menu that most suited the roles and resources they had working in their IT shops, and provided a step by step method that would work for them.
Something else to consider is that an architecture, for a system or enteprise, consists of many architectures within a framework.  One should note that many methodologies may be used to complete or document the architectures.  For
example, one might use the ITIL Methodology to complete many components within the Technology Architecuture, The Rational Unified Process to complete components within the Application Architecture, and the IDEF Methodology to
complete Data Models within the Information Architecture.
Within your organization, someone will need to establish a framework on which to based your architectures, and any
architecture initiative must be managed as a process and with a strategy that utilizes both a framework and a method-
ology to collectively organize the objectives of the process steps and how to complete them.  The framework will identify and organize all areas or domains of concern.  A methodology will help you develop a consistent approach in addressing
all the issues and components related to those areas identified by the framework.  At a minimum, you must adapt a
project management methodology.
I would also highly suggest adopting a development methodology, and urge you to review the most popular.  Doing what
is considered to be best practice or industry standard will allow you to have the most choices for tools, training and
documentation.  Keep in mind that the UML is not a methodology, but a notation, but it does provide several
types of diagrams that, when used within a gien methodology, increase the level of understanding of an application or
system under design.  The standard diagrams can be part of our design and development methodology.
Another way to consider methodology, is an approach or guidebook for each cell in an Enterprise Architecture if
you think about it with the popular Zachman Framework in mind.
As I always finish with a tip, I’ll leave you with this:  In the case of Methodologies, one size does not fit all, but
there is a lot to be said for the industry standards or best practices in this case.  If you can’t find one that
exactly meets your needs, take the closest one and tailor it to suit your environment, or call in an expert to help
you do this.

IT Architect Skills

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.

The Role of the Architect

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!