Happy Holiday Weekend to my Canadian Friends, 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 Read the rest…

First of all – reminder that the deadlines for early bird pricing on the Architect Boot Camp workshops in October are creeping up on us.  Get your registration completed and reserve your spot at Early Bird Rates!  There are limited seats, and all we need is your registration, and you’ve got your spot.  We’ll send you confirmation and invoices. 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 Read the rest…

It’s nearing end of summer and slowly, folks are getting back from vacation or they are out shopping for school supplies.  Maybe a last minute golf game with friends, or perhaps colleagues.  A day at the beach if weather permits.  As we see the first signs of the leaves turn Read the rest…

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 ** Read the rest…

In putting some efforts towards my fall seminar schedule, I have been focused on my technical 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 Read the rest…

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. Read the rest…

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 Read the rest…

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 Read the rest…