Technology Landscape - Your Best Target?

In putting some efforts towards my fall seminar schedule, I have been focused on my technology architecture workshops and had a thought today worth sharing.

As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.

We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.

IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.

The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it's difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.

What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn't change often. Meaning - if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we've determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year - or which direction we intend to move as big changes are made.

These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of "cool and new" technologies, unless innovation is our core business product.

In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn't possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.

Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.

If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.

Setting Your Scopes

Recently, one of the people I have been coaching in the area of Enterprise Architecture asked me a great question - one worth posting here. He said "what is the scope of the Enterprise Architect?" in context to the head of Application Development, the Lead Analyst or the Solution Architect.

I responded within the parameters of Enterprise Architecture at a company. EA provides IT governance and stewardship for any future technology planning and roadmap within a company or organization. An architect considers fundamental business drivers, structure of a system, it's components and relationships and then creates or tunes the best design to meet the needs of the business drivers and the organizational goals.

In most organizations, there are many systems that may cross boundaries, and many people in various roles with varying responsibilities that blur these lines. Evolution of one system to achieve a goal is often not achievable without understanding the relationship to other systems. This is the scope of Enterprise Architecture and the EA - he or she must know about the scope of all the systems and make the best decisions possible for the greater good of the organization.

The scope includes knowing how systems and their components interact, and their relationships to other systems and their components. Scope of EA includes the principles that govern the design and evolving life of all of the systems. The skill of the enterprise architect is in their abilities to see things conceptually, and be able to scale up or down, seeing bottom-up and top-down whenever they desire to take another view, and to keep this is mind when making key and fundamental decisions.

They require the understanding of it's relationship to all of the systems, needs, goals and desires of the organization. Making decisions without understanding this relationship is like designing a community in the desert without considering how air, rail and vehicle travel will reach it - the distance to the nearest power, water and electrical resources, and position on earth's topography for all such needs. Regard for infrastructure is critical, and the style of the community based on earth's disasters is the responsibility of such a planner.

These kinds of responsibilities like with the Enterprise Architect, so understanding the fit of the system to the organization is like the analogy of a town to earth's landscape and the planners who must create great places to live. The EA is also responsible for ensuring that growth of the town can happen naturally, without crisis and that effective living can occur when introducing new services that those who dwell here need them.

What is the same, and what has changed?

Someone asked me a philosophical, yet, appropriate question the other day.

Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else - BOAIT (business, organization, application, information and technology).

I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.

We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we've hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).

Do we use Zachman, Dodaf, FEAF, or something else? It's all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise - it's about doing and using architecture, not just defining it.

My answer is simple. I started with a very excellent book that was very appropriate in the mid 90's. It is Steven Spewak's Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change - we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.

Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.

Nothing has really changed my perspective - just some of the details around how and why I would collect, analyze and interpret what I've categorized.

Architecture or System Requirement - What's the Difference?

Lately, I've been working on the Architect Boot Camp info site and trying to lay out some really basic architecture information and some more advanced stuff. It dawned on me that there might be some who don't understand the difference between system requirements and architectural requirements. If this is news to you - stick with me. If not, I won't waste your time - catch you later.

Architecture requirements are typically those you collect during the initial scoping and context setting sessions at the beginning of a project while you are collecting high level system requirements. You need to determine the business objectives for the system, and for the architecture specifically.

It is so important to ensure that the architecture is aligned with the business drivers and objectives for the project. The architect keeps his or her eye on knowing where VALUE WILL BE ACHIEVED. What are the stakeholder goals? Main criteria for success?.

Setting system context helps to measure scope and set the appropriate boundaries. The architect needs to understand what the system interface will be, and what factors will characterize the architecture. Getting a list of top-level and high-priority goals will assist in setting this scope. This list can be further expanded when moving towards the elaboration phase of the project, and further gather the functional requirements.

The infrastructure must be designed to support the services and functionality that users require. It must deliver the appropriate levels of performance, security, usability and flexibility. All are factors that must be considered at the very beginning during the structure design and concept building of the solution architecture.

If the product is being purchased, the solution or system architects must review the requirements in order to determine their relevance and completeness. Specifically - those relating to non-functional requirements - specifically in the areas of performance, volume, methods of doing transactions or using the system, whom will use the system, how they will use it, etc. require review by the architects.

The architect must also ensure that these architectural requirements align with the Enterprise Architecture view. There are standards that are set for an organization, and typical infrastructures and patterns that are acceptable. Knowing, studying, analyzing these considerations in advance make up the architecture requirement gathering efforts for the early stages of the project.

These requirements need to be included in the solution architecture documentation set, and potentially used for volume, stress, and usuability testing during prototyping stages if the technologies are new, or if the requirements are risky.

Pure business functionality are user and system requirements. These are typically gathered by the systems and business analysts. An overview of such requirements should be held with the architect to ensure that they don't become intermingled, but there are shades of grey when it comes to "which documentation set" they belong to. You are a smart individual - you'll figure it out.

For more on architecture how-to's, visit The Architect Boot Camp.

Happy Architecting!

Decisions Decisions

Long time, no type. I've been busy - but now have the time that this deserves.

I've just spend a near year acting as the Chief Architect at a large Canadian insurance company, and have many thoughts and insights I've love to share.

Here is one of the first.

Often, an architect, especially the chief architect, is asked to make an architectural decision. Typically, an IT resource is asking him or her to make the decision, but what needs to happen is the requester has legwork to do.

Typically, a high level assessment of what would be required to deploy the decision in the prospective environment is necessary. It is typically works done by their team, or by operations, or an application team.

The goal is to provide you with some key drivers you can use to make an informed decision. Although we would not perform a detailed assessment of the technology or solution, we would examine it at a high level the with the resources at hand.

The requester should then present this to the architecture team so they can make this architectural decision an informed one, and ensure the deployment on the platform of choice is valid.

In detail – the requester needs to do the following:

1) Assess and document the root problem being addressed.

2) Provide an overview of each option / alternative.

3) Give a Summary of evaluation criteria

4) Give a Comparison of each alternative relative to evaluation criteria.

5) List of "Implications" and "Impacts" of the recommended decision (assuming they have a recommendation).

Ideally, we'd like to reach a conclusion in the meeting together. Typically, questions that arise because resources are asking for a decision tend to raise a lot of questions when presented for the first time - leading to take-away work to gather specific information /research to feed a final downstream decision.

Time is usually in short supply, we'll attempt to work to the goal of a recommended decision within the meeting and the architecture team can provide guidance on the type of trials, prototypes and tests required in order for them to either raise this to the architecture review board, or make their decision.

Quick Wins in Enterprise Architecture - Part 1

Happy New Year! It's nice to be back again and writing about my favorite topic.

This spring I'm speaking at the Enterprise Architectures Conference on Quick Wins in Enterprise Architecture so I thought I'd share a bit of the content.

Enterprise Architecture as a new program within a company or an organization is difficult to kick off. Often there are so many things that need to get done, that we are overwhelmed. We might resort to following recommendations or readings we might find in a book on EA, or from a paper, or even a framework.

Many newbies will get a framework and attempt to start filling in the cells. Others might pick up Spewak's book, or some other writing and start with a pure planning method in which we capture Goals, Drivers, Strategic Direction and then Current and Target state with hopes that it will eventually turn into a migration plan and eventually projects and a set of standards and principles.

If you make a quick list (take no more than a hour to do this) of the things that you would like to include in your plan and then EA projects that are most needed at your organization. In speaking with my CIO today, he said that a list of what we had depicted graphically with a target state mapping and then a status for each technology with respect to "contain, expand, conclude" or other such terminology to state plans for their use going forward. Even in a very large organization this is relatively attainable unless you are very distributed.

It is perfectly acceptable to have multiple technologies within a domain. For example, you might designate one database technology for small and medium applications, and another for large enterprise applications or solution specific applications where there is none or little choice.

Statements as to whether or not you will acdept or embrace open source, and the types of platforms that are suitable for technology "families" or categories of activities to be performed on one particular type of service (Unix flavoured or Intel for example), is also very helpful. General guidelines will help teams when they are searching for solutions.

Well - this is just a hint of what will be included in my topics and further writings.

Happy Architecting!