If you ask just about any IT Director, Manager, or even PM, they’ll tell you that Architects are amongst the toughest resources to find.  I’ve experienced this so often either when helping clients build their teams, or when I’ve tried to build them myself.

Architect Boot Camp training was designed to help organizations train their own staff, or to help those in IT who have an affinity towards high end design & IT Strategy, but want to hone or learn Architect Methods, Process and Approach.  The objective is to deliver the theory, while using real life scenarios and then practice through case studies and exercises.

This fall our IT Architect Boot Camp workshop is now full, and we have but one spot left in our Solution Architect Workshop.  We had to move to larger space to deliver the workshops, and I’m sure with the great mix of staff and experience, they’ll be a good experience for all attendees.

If we can’t find architects, we’ve got to grow our own.  We need to optimize our IT dollars, and now more than ever we need to make sure we’re building and designing the right things.  Just ask John Zachman - he’ll tell you that Architecture is the ONLY way we can improve our success rate.  Only three days to go until the start of this first public offering this fall, so this blog entry will have to be short.

By the beginning of November, there will be several more architects ready to provide value to their organizations.  We must applaud organizations who believe that investments in their people are good ones, and won’t be impacted by rough economic times.

Happy Architecting

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!

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

Hello from the eve of yet another EA Conference

Here I sit in Calgary, pondering some thoughts with respect to the topics at hand at tomorrow’s EA Directions “Critical Issues In Enterprise Architecture and Strategic Alignment” two day conference. I have the great honour to present on several EA topics including some in the area of SOA.

Last week, at one of my Architecture Boot Camps, the Technology Architect Boot Camp, I had another great experience with a very talented group of individuals from a very diverse set of enterprise experiences.

We discussed the role of the technical architect at length, and specifically that which pertained to services in an SOA and the TA’s role. Two very distinct areas that I may not have paid enough attention, were consideration for the specific security concerns that are heightened with an SOA.

I did not specifically high light this as a non-functional requirement, but likely should have. It is easy to rattle off the usual suspects such as availability, reliability, blah blah blah. But Security doesn’t typically fall into this camp. It may be both functional and non-functional, and should likely be included in that checklist that we architects all peruse when thinking through those considerations that most don’t.

Another point worth mentioning, is another complex issue surrounding SOA. After creating and designing the architecture for SOA, we need to ensure we’ve included an architecture that encapsulates the nature of monitoring, metrics, measurement and management of the operational aspects of the SOA-based services platform.

I feel so strongly about these subjects, that I will soon release a special report on measuring such important details of the architecture environment, so come back and I’ll be sure to share.

With both of these as critical factors in the SOA, it is very hard NOT to include the Technical Architect in both the design of the initial SOA infrastructure, infrastructure and platform, but should highlight the benefits of including such a role within your overlapped EA and SOA teams in order to ensure you have the right minds creating the best solution for your enterprise.

Happy Architecting,
Sharon

Mergers & acquisitions – Calling All Architect’s – We’ve Got a Merger & Acquisition

What are your IT Project Priorities – do you have one of those “Yours, Mine & Ours” situations???

What I mean is that when a business decides to buy another company, or merge with one, often there are multiple perspectives to project priorities. If one business arm decides they need a bigger sales force, and another wants to gain proficiencies in a manufacturing process, there may be conflicts. Add the fact that the IT area wants to streamline, yet add or upgrade technology infrastructure, we’re cooking up a recipe for missed expectations.

The IT Architect needs to understand what the end goals are by the business when creating the architecture. If you want to read more on ensuring you understand the right messages and goals, why don’t you check out my information site - Mergers & Acquisitions and the Information Architect is an article that addresses this topic.

It’s a sample exerpt from our eZine “The Architect Abstract”. Head to the site to sign up to get a copy every week, or view the sample articles to whet your appetite.

Happy Architecting!
Sharon

Do You Have a Crystal Ball: 3 Future State Architecture Keys to Make them Think So!

Documenting the current state architecture is a must to any enterprise or system architecture report, and even though we understand this, it’s the future state that everyone is anxious to see and share. Let’s face it – they are also waiting to critique it. There are components of a future architecture that make or break its impending success – or failure. It seems that there are three surefire keys that you can include to ensure success!

Let’s suppose you are responsible for the System Architecture or Solution Architecture for a new custom application in your enterprise. What mandatory items should your checklist include when documenting the future architecture?

1) Strategic Direction

Opportunity creation can be achieved by analyzing relationships between Strategic Drivers and Business Architecture Components. Those who need to buy into your future state architecture need to be able to visualize the opportunities, and taste those benefits! The business architecture should include these items to articulate strategic direction:

• List and adequately describe the Strategic Drivers behind the architecture. If there are many to be listed, separate them into “Primary” and “Secondary” or some other tiered scheme.
• What new opportunities will be addressed by the new system?
• What potential future opportunities are on the horizon can be accommodated by the future state architecture (read flexibility!)

2) Justification should be the key focus in the System Architecture (Application & Information). You will gather information for justification of system enhancements while analyzing the relationships between the Strategic Drivers and the System Architectures

• Define what kinds of application systems will be relevant to the enterprise (based on strategic drivers)
• Describe the application as logical groups of capabilities that manage the information (capabilities that match to the strategic drivers)
• Describe the methods that support the business functions described in the Business Architecture (Linkage)

Include these items in terms of both the Application and Information, and you will have justified the new system.

3) Automation Efficiency should be the key focus in the Technology Architecture. Benefits can be collected when analyzing relationships between Strategic Drivers and Technology Architecture

• Describe future standards and technology principles required to support the new system (based on the strategic drivers)
• Describe the technology platform required for the new system
• Describe the anticipated distribution of data and applications

If you are able to create a visual presentation for your audience, include these three main points on your agenda – tell them that you will prove that your future state architecture provides alignment with strategic direction, added capabilities to enable business drivers, as well as automation efficiency using technology, and I’m sure that you will definitely have an interested audience!

For up to date information on IT Architecture, visit www.architectbootcamp.com.

Happy Architecting

Sharon