Making the Case for IT Architecture

There are still quite a few misconceptions in regards to IT Architecture. For many, hearing the term "Architecture" in relation to any IT topic seems to imply Enterprise Architecture (EA). To others, the notion of formal design processes represents the anti-thesis of Agile or responsive problem-solving. These misconceptions are unfortunate because there has never been more architecture connected to IT in actual practice and there has never been so much need for it.

So, let's start at the top - IT Architecture is a continuum and an umbrella for every design process in the enterprise. IT Architecture is the foundation for understanding every enterprise capability as well as being the starting point for all planning and governance. The reason it serves all these roles is because it provides the necessary insight for guiding all of those processes. Without that insight, making decisions and governing IT management or evolution becomes more or less like guesswork.

Why should this be so? Well, it has a lot to do with the disruptive and dynamic nature of Information Technology; it is not all uncommon for large organizations to have incomplete information in regards to their own systems, costs and data. Often times there are redundant, distributed islands of IT that cross business units or may even involve the separation of capability across IT & business communities. Gaining a complete picture of what's going in many organizations is quite a challenge - but is absolutely necessary in order to unify systems operation and to move forward in a coordinated fashion to exploit new opportunities and technologies.

So, let's go back and address those two very common misunderstandings again…

1 - IT Architecture and EA are the same thing (and EA is useless) - now I've paraphrased some of the criticism I've heard over the years about EA, but of course there is a legitimate question there. Is there any real value to EA? First off, EA and IT Architecture are not the same. EA is a top level architecture process and represents perhaps 20% of the total architecture that occurs in the typical enterprise. EA is integrated with IT Strategy and portfolio planning and governance.

Does EA have value? Yes, it does. It represents that portion of IT architecture that helps allow business stakeholders understand their IT capability landscape. It is high level enough to function as a communications tool, a governance framework and a project estimation bench-marking tool. EA is also, when done properly, the bridge to all other solution architecture.

2 - Does Architecture inhibit Agility? This is a thorny question and a complex topic, but I will try to address it briefly. At first blush, it might appear that any formalized design process might not fit within the context of the Agile Manifesto. But there are some important considerations worth noting that tend to contradict that initial assumption:

• Agile, as a methodology, has never been effectively transferred from a system or application scope to an enterprise scope except through the adoption of more iterative, time-boxed approaches to lifecycle management. There is a good reason for this - purist Agile approaches are focused on deriving requirements through experimentation rather than up front design.
• When you move from the application development scope to the enterprise integration domain things change - a lot. The problem at this level is no longer invention, but reconciliation and complexity management. In this context, the discovery associated with design relates to existing capability and introduction of well-defined new technologies. Here, IT Architecture provides the reference point for establishing and maintaining control over what otherwise might become a chaotic environment.
• Agile is all about making the application work by any means necessary - operations is all about making the enterprise work as a whole in the most efficient manner possible.
• And even within Agile, there is a design process and that process is merely one specifically-tailored component of a larger family of IT Architecture practice.

Perceptions are often hard to change and IT Architecture is a large, emerging and complicated field of practice. After working as an architect for 16 years, I can honestly say I've never seen more organizations doing architecture work. More often than not that architecture has become an important part of their overall IT management strategy. Yet, the continued misconceptions tend to hold back the true potential of IT Architecture. Too often, people view it from the perspective of one of the many sub-disciplines (such as Agile design, etc.) rather than seeing it as a holistic enterprise resource. I think that as the realization of its true scope becomes clearer IT Architecture will become even more important in the years to come.

copyright 2014, Stephen Lahanas

Read More

Why Requirements Still Matter

IT Architects deal requirements in many contexts; there are requirements associated with the management of architecture itself, the requirements of the enterprise which drive an entire portfolio and the more specific detailed requirements associated with solution design. Today, we're going to examine the requirements in the context of Solution Architecture - a domain where Agile is sometimes interpreted as a "requirements-free zone."

These days, requirements management is often misunderstood or under-appreciated in IT. Many people have used migration to Agile methodologies as an excuse to discard requirements or rethink how they’re used to support most projects.

In the overall lifecycle of lifecycles, requirements becomes critical in establishing traceability

One of the key tenets of Agile application development is not to over-think technical requirements in advance. The premise is that it’s usually impossible to accurately predict the details, which would invariably lead to costly rework after the fact—as opposed to an Agile approach of incremental refinement.

So who’s right? Do Agile advocates make a convincing case that a too-precise definition of requirements is counterproductive, or does the more traditional view of requirements management make more sense? Before we answer that question, let’s review several pertinent factors:

• Not all IT projects involve coding (for example, software development).
• Even Agile methodology includes some level of requirements definition.
• Many, if not most, organizations track “functional” level business requirements, a task usually managed by business analysts.
• The majority of people who collect and manage requirements don’t follow a specific methodology, since it’s often considered less important than the follow-on development or implementation activities. What’s more, most people don’t realize that requirements management is a collaborative activity.

Maybe both camps are wrong, or perhaps both approaches suffer from a similar flaw. Traditional requirements management and Agile requirements represent two ends of a spectrum—and each assumes the other end is ineffective.

Common Ground

As in most things, the truth lies somewhere in between. Not all requirements are the same, so they shouldn’t all be managed the same way. Either camp could go wrong in this area. Also, the main reason that requirements management has come under criticism isn’t that defining solutions up front is intrinsically wrong, it’s that defining solutions out of context is.

Followers of both traditional Waterfall and Agile techniques can fail to define solutions in context. The difference is that with Agile, the flawed results are more likely to be noticed early. Context can be lost when a team develops requirements without:

• End-user input
• Stakeholder input
• Use cases and test cases
• Mechanisms for validation and incremental development
• Integration of business and technical requirements processes.

It’s worth pointing out that the controversy over whether requirements management is a worthwhile practice hasn’t led to widespread insight into how it can be corrected. Instead, it has led to sporadic use of requirements or a complete disregard for them. Meanwhile, even with Agile, the success rates of IT projects haven’t improved all that much.

The Best of Both Worlds

Requirements management is the most logical place to integrate business and technical processes and teams. Instead of moving from one either/or philosophy to another, we should take the best elements of each camp and create a better approach.

Far from abandoning requirements as a central part of every project, it’s time to start advocating their use in all projects. Here’s why: Requirements are the foundation of all good design and architecture, all portfolio and project management, and all project or solution collaboration. If compiled properly, they capture vision and thinking from a diverse spectrum of team members and document the solution as it’s progressing.

As we said, not all projects need to apply requirements the same way. Conditional requirement approaches might be applied to these project categories:

• Pure Development: Little or no code reuse. This might involve a more Agile approach, including more experimentation and more test-driven or scenario-driven requirements.
• Commodity Development: Significant use of existing libraries or software packages. This might focus more on integration and performance requirements. For example, an existing knowledge base may support more detailed technical requirements.
• User Interface-Driven Solutions: Much more focused on event-driven expectations and extensive user stories.

Requirements don’t have to predict all aspects of a solution, and they can be corrected or updated as the solution emerges. They can easily become evolutionary in nature. The bottom line is, don’t skip them. Compiling them now can save you a lot of trouble later.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Difference Between Enterprise and Solution Architects

I'll preface this topic by stating up front that very often Solution Architects (SA's) and Enterprise Architects (EA's) are the same people. There's no reason why EA's and SA's can't fill each other's roles and in fact this happens quite a lot. Having said that though, there are differences between the type of work you'll be asked to do as a Solution Architect from the tasks you'd be asked to perform as an Enterprise Architect. It is also important to keep in mind that both roles share common skill-sets which is why both roles can be grouped within the umbrella title of "IT Architecture."

We'll start by providing some definitions:

1. Enterprise Architect  -  An Enterprise Architect is someone who is charged with helping to define cross-domain capabilities and solutions for an organization (or in some cases just documenting them).  An EA is definitely a big picture role - one focused on how issues, projects and systems relate to one another in ways that aren't immediately obvious to those working within the context of individual projects. EA's are often also asked to establish, populate and otherwise maintain enterprise architecture / knowledge repositories.  These enterprise architecture resources are used as a Reference Framework or starting point for all other IT activities (when it's done properly, that is).

2. Solution Architect - A Solution Architect is someone who is charged with defining and usually implementing specific technology solutions.  This role is often referred to as a Project Architect, but can just as easily apply to any type of IT resource referred to as an "Architect" (e.g. Data Architect, SharePoint Architect, Security Architect etc.). The SA role is more focused on software development lifecycles (ALMs) than the EA and is often tasked with following a solution throughout that entire lifecycle (be it months or years).

If these definitions sound a bit open-ended, they are - but that's primarily because this is how they're viewed by employers.  The SA role in particular is fairly hard to pin down because almost any IT specialty these days can have an "Architect" role assigned to it. As the SA role becomes more technology-specific, it moves further away from the generic vision of an IT Architect who could conceivably move back and forth between and SA and EA roles. For those who aren't completely invested in one specific technology though, there does exist a common set of capabilities or skills that both EAs and SAs tend to share:

• Problem-solving or analytic reasoning - This is often referred to as "Critical Thinking" but unfortunately academia has never quite standardized what that means. For our purposes, "Problem-solving" refers to the ability to apply one or more problem-solving methodologies to bear in order resolve any type of technical issue (it can be a personal problem-solving approach or one associated with any number IT methodologies). 
• System Engineering Skills - Often times people lose sight that architecture is in fact an engineering as a well as design-focused discipline.  Systems Engineering helps provide the ability to think through constraints, dependencies and relationships. It also provides valuable insights into how standards are developed and deployed.
• Design Thinking - This is a bit of a buzz-word but it helps to emphasize the creative nature of architecture. Analytic and System Engineering skills will only take you so far; creativity brings you the rest of the way.

Any Architect who works or has worked across multiple technologies, either as an SA or EA will have equal application of the skills listed above. The number one skill though for any EA or SA is this - the ability to take those common skills and apply them to an entirely new technology or problem.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Solution Architecture Defined

Solution Architecture is sometimes also referred to as System Architecture or Project Architecture. It differs from Enterprise Architecture both in scope and the level of detail. Generally, Solution Architectures are also more narrowly focused (sometimes on a single system or system component  scope) and are usually more detailed in regards to both implementation and configuration. People often view Enterprise Architecture as more strategic and Solution Architecture as more tactical in nature, but in real life this boundary is often blurred.

Solution Architecture is also much less agnostic in nature - in other words, it is more likely that Solution Architecture will contain a great deal of product or specification detail. If we view EA as more Conceptual or Logical in nature - Solution Architecture falls somewhere between Logical and Physical description.

This illustration represents an example of Solution Architecture...

Architectures working at the solution level might have to deal with only one major technology (lets say, PeopleSoft, which in itself is somewhat complex) or as many as a dozen. The context of the work is the boundary of the solution. If the solution or project is focused on securing PII customer data the scope may include all the databases that hold such information, an ESB tool for data movement and an identity management suite for authentication and authorization.

There is a wide diversity of opinion in regards to how Solution Architecture should be practiced or scoped. There is also a relative lack of industry guidance as to how organizations ought to align Solution Architecture with Enterprise Architecture. We will explore these issues in greater depth in future posts.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More