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

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

Recently I was asked that if a person was already acting in the role of a software integrator, did they really need to learn how to be an Architect.  The answer was a little bit complicated, but it was an emphatic “yes!”

While the basis or core skills of a great IT architect does come from solid software integration knowledge and practice, the basic practices, approaches and thought processes as well as ways of thinking in the correct context is what is taught during an IT Architecture workshop.  Various approaches and ways of thinking allows an IT Architect to get a new perspective of the various contexts they must review before choosing a solution or constructing an architecture.

There are various thoughts on how one becomes an IT Architect, and granted there are so many ways to get here, the result is the same.  In order to become good or even excellent, the Architect takes on a different mind set.  There are various perspectives that are reviewed, and as well, various options with respect to ways about thinking about the issue, problem or opportunity are reviewed.

The architect considers more than fitting two pieces of software together, and the approach learned in a workshop will take them through the business objectives and IT Enterprise objectives, through to the various decision making techniques and options for formulating a solution.  Typically the instructions given to an integrator are taken after an architect has determined the best approach and seen best fit for the components that are selected.

During these exercises, the architect takes on a different approach with respect to requirements analysis, solution review, as well as some softer skills to deal with the political and communication parts of the equation.  Often integrators are given something very specific to be done, as well as a roadmap for doing so.  The architect takes part or creates that roadmap, and many more variables are considered than may be actually visible to the integrator.

Finally – there are various approaches that an architect learns to getting from A to B.  They learn to view a solution from a multitude of angles, and those which will enable them to see their way to the minimal path of risk.  In part, the approaches are part of the culture of the organization for which they must have an appreciation for, as well as a component of the overal IT & Business Strategies.

Hopefully that sheds a bit of light on the benefits of learning to become an IT Architect, rather than skipping these important steps.  For more information on training, see our site.

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

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 color, we turn to that busy planning month of September.

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.

And What’s the Difference?

It’s been a long time since I wrote part 1, but I’ll try to get the next few parts out asap.  If you recall, I was writing about the purpose and reasons for Enterprise Architecture.

Along with planning and strategy, execution is critical.  We must create and tailor our messages for our audiences in the most appropriate manners, and continually educate and grow support for the program.  If the business community cannot see value in this endeavor, then they are not ready.   That is yet another subject to be explored else where (ask me about readiness assessments).

You – the Chief Architect or Enterprise Architect, may have to put on a few public presentations – or private.  Each must be carefully crafted for the audience at hand.  If your organization is very green – well – they may need the “what is architecture” speech.  If they are more advanced, and you are purely looking for funding, you need to really familiarize yourself with the business strategy, cherry pick a few points, and then use a very carefully selected set of benefits and craft a presentation.

The presentation may have to be tailored for each audience you visit – the CEO/Funder, the CIO, other IT Groups, other business functional groups, consultants, and any other external support.  Before crafting the presentation, create a mind map or “story board” of your intended audiences and key messages that you wish to share.

Your sole purpose of such an exercise is getting buy-in!  It might not be actual funding, but you need to gain momentum so that you can get it once you ask.  They must understand before they can grant you their support.

Sponsorship vs. Support – There is a big difference!

Sponsorship is where a person or group pays for and assumes responsibility for the effort to be carried out.  This is usually the CIO, and potentially the CEO or IT Steering committees.  Support is someone or groups that support the effort or initiative.  They uphold, defend and promote EA as valid or the best approach by lending their assistance and public support.  Support is sought by all groups and domains that are affected and impacted by the creation, development and finally governance of the Enterprise Architecture.

Sponsorship and support require continuous education, promotion and communication.   If you want more information about the tools and resources you would need to uphold such an endeavor, get the entire report

Happy Architecting

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.

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!

Here I am again, bleary eyes but wanting to share all from this year’s Fall EAC. I have so much to share, and tonight will just have to be a summary. I catch the red eye in 6 hours, and suitcases still have to be filled – you know the drill.

This year was a little different. More keynotes, but fewer messages. The last one was fabulous, so all is not lost. John Zachman has finally admitted there is no silver bullet and still maintains that one day we will all wish we’d filled his magic framework. I’m not arguing but there were more that agreed with me this year that feel practicality is a virtue.

The conference offered two panel sessions this year, and not as a keynote. Great touch – heard some great things except for a 30 minute drone about certifying EA’s. There is much passion about this, but hard to get excited after listening to it around the CIPS ISP. Sort of boring and so far from reality. Perhaps we should work on a common vocabulary as I hear more acronyms that you can imagine for what goes on in the Business Architecture. Reminds me of the early nineties when modeling tools first entered the scene and with a flick of a button you could create a new flavour of the day – all of which equated to a logical or process flow diagram.

There was an increase in both the sessions and numbers of folks who attended the “Build” as well as “Run” Sessions. Good for you! This just means that there are the masses attending the Plan, meaning we still don’t have anything done yet.

The most common question I heard all week was “how do we know when we’ve modelle enough?”. Various answers – deserves a blog onto it’s own – but all it means is that we’re progressing.

Well – have to type more tomorrow – 4 bells come early and I will take a break from this little stanza.

Happy Architecting and Happy Friday!
Sharon