Some of you luck ones may have fled your cubes, offices or project rooms – and for those of you left, you might be in for a little reading.

If you have been considering the Canadian training coming up October 20-24th, there are still 3 spots available in the IT Architect Boot Camp workshop, and 4 spots in the Solution Architect workshop.  It will exciting as the exercises and labs have been a real treat to create and will be fun and challenging for the participants.  I truly wanted the attendees to experience what it was like to be put into the position of being an IT Architect, and a Solution Architect in a variety of situations.

For those of you watching the Google Group posts, or the IT tool box posts, there has been one of the most lively weeks I’ve seen for a really long time with many chiming in on the “types of architects” threads.  I’ve almost jumped in many times this week, and it took real discipline to get back to the training preparation I have been doing, and to keep my eyes off of the email, as well as dismal world news that is flooding our eyes, ears and households.

My hope for all of you is that Architecture is, and will remain to be alive, well and thriving in your companies and that those around you see what an incredible job you are doing with your projects and programs.  I hope you are in a position to enhance and tune your skills in the soft skills area, as well as in the areas in which you consult with peers and business folk alike.  During these tough times, you may be called upon to come up with some creative ways to continue business with less funding, and help the teams in your finance areas plan quickly.

If we can use some of the scenario analysis skills we’ve gained during our architecture training, as well as skills as an organizational politician and consultant, we should be able to add value to our business teams as they are trying to figure out how to continue to move towards corporate goals.  One of the soft skills we rarely touch on is empathy, and just trying to really understand what they are going through, before pressing on with the transitions that we had planned for systems inthe company is one of the things we can do to help.

It is your job as the architects to constantly keep a finger on the pulse of your business stakeholders.  Rather than keeping our heads down and surging forward with our work, we need to check in and make sure that they still feel that we are going in the right direction and that we are still spending our time and energy on the right things.

Happy Thanksgiving to my friends in Canada, and Happy Architecting to everyone.

Sharon

Want to become a great architect?  Why not join our Architect Professional Site – entirely aimed at creating GREAT IT Architects!

I’ve been answering a few questions in email lately, so I thought I’d add the questions in this blog:

Question: Do you see a big benefit from the Solution Architect Workshop (SAB)?  What’s the difference between it and the Information Architect Boot Camp Workshop (IAB)?

Answer: The IAB will teach you what the role of IT Architect is, how the various types of IT Architects are interrelated, how they fit into the project lifecycles, and how to be an architect practitioner.  You’ll learn the skills you’ll need to play any architect role and the basic architecture methods and process.

The SAB will teach you how to do solution architecture, review many options and put together solutions.  You will learn the skills as well as the steps and process to complete various Solution Architect activities and artifacts.  It is the best course for someone in a project architect role, provided the attendee already knows how or has basic IT architect knowledge and skills

Question: Should I take both of these courses together?

Answer: As we go through the IAB workshop, we are going to practice the various IT Architect skills as they are taught.  We’ll work on a project throughout the three day workshop, and each successive step will build on the previous, so that we will have gone through a typical Architecture activity from start to finish after we have spent three days together.

In the following two days in the SAB, we’ll learn more about putting solutions together and about the various scenarios the Architect faces when asked to create or update the architecture.  We’ll use the existing Architect’s skills if the attendee is just joining us, or the skills just acquired in the IAB if they are continuing.  It is not necessary to take both, but if you are a self-taught architect, it would be beneficial to take both together, to learn some of the best of breed approaches, and practices.

Question: What happened to the 1 day Architect Boot Camps – The Introduction and the Executive Architect Boot camp?

Answer: These training sessions have been held multiple times in the last few years and demand wasn’t high following the catalog release.  These classes are targetted to be offered as an online offering in October.  There will be some self-study, and some instructor/participant interaction offered.  More information to follow – stay tuned!

Question: Where are the classes being held?

Answer: Currently we are only scheduled for Winnipeg in October.  We have plans to offer some classes in Phoenix Arizona in 2009, and are currently looking into demand in other large Canadian and U.S. centers.  Classes are always available in group settings.  If you are interested in booking a class for 6 participants or more at your workplace, contact us for more information – choose the option of “other” for location and fill out the rest of the form.

Question: Do you offer a coaching and mentoring service?

Answer: Our online coaching service will be released today – more information later on.  We do also offer Enterprise Architecture coaching through EAdirections.  For more information on either of these services, please contact us, or watch for our information blast coming out shortly.  If you would like to get on our list for notification, please fill out the contact request form.

If you have more questions, or have other architecture problems or questions you’d like answered, please give us your comments.

Happy Architecting

We all get back from the lazy (lazier?) days of summer, and think about how we can get back to changing the world.  If we were lucky, we’ve made progress in our Enterprise Architecture Programs – or perhaps not so lucky, but were the beneficiaries of good planning – to keep the program moving forward.

Most companies take a fresh look come September – and feel it’s their new school year.  And with that comes planning.  And hand in hand with the plan is our strategy.   The Enterprise Architecture team and program need to create a strategy early in its life.  We need to develop both a sponsorship and sales plan.  We need to analyze our organization and determine whether or it’s metrixed.

If so, you have a strong culture of process discipline.  Evaluate the organizational maturity by figuring out how well the entity will tolerate change and watching the development of a grand strategy unfold.

As mentioned previously, it is critical to identify the stakeholders.  If possible, you view the enterprise, and determine where the market is for EA.  In doing so, you need to know where the locus of power resides, who is respected, who is ignored and who has the political capital that is required to drive such a large initiative.

Your strategy flows forth from the analysis of your stakeholders.   Create a matrix yourself as part of your strategy analysis exercise.  For each stakeholder, know which product they would be interested in, or benefit from.  List what value they would gain and what your competitor positioning would be.  Identify who might also offer the same “products” to your stakeholders.  Know their strengths, as well as their weaknesses.

Part 1 of 5 part article…

The primary purpose of an Enterprise Architecture (EA) is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments.

The true challenge of enterprise engineering is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.

In general, the essential reasons for developing an EA include:

• Alignment—ensuring the reality of the implemented enterprise is aligned with management’s intent

• Integration—realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise

• Change—facilitating and managing change to any aspect of the enterprise

• Time-to-market—reducing systems development, applications generation, modernization time frames, and resource requirements

• Convergence—striving toward a standard IT product portfolio as contained in the Technical Reference Model (TRM).

Selling EA vs. Building Support

The single most difficult task in delivering and developing and Enterprise Architecture program is gaining support from the enterprise itself. This is why I was so passionate about writing this report. There are many bumps and detours along the way, and if we all can avoid and maneuver them, EA will advance as a whole and become more accepted and understand.

There is little reason to start an EA program itself unless it is supported by the business and treated as a business initiative. It will require executive level commitment and persistence. The IT department should not have to continually go to the well in various user organizations to get their support if there is a good plan and strategy in the beginning.

Want to read the rest? Get my Ten Secrets to Selling Enterprise Architecture and download the entire 33 page article.

** Note – As of Jan 1 2009, this report is no longer available publicly.  If you want the details, go to our Membership Portal **

Happy Architecting!

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.

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.

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 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!

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.

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!