How can the Chief Architect Absolutely Guarantee Value?

Why does the business demand change?   This is the fundamental question you should asking yourself as a Chief Architect before doing any architecture work.

Many current IT strategies and architectures are failing. Senior business executives report that fewer of 25% of IT projects achieved defined project level goals. Fewer than 12% of fundamentally advanced the business strategic goals of the enterprise.  Why is this?  Why are failure rates so high?  Why should the Chief Architect be concerned?

Many IT projects are focused on the wrong problems at the wrong time.  As the chief architect, your focus must be in providing value to the business in the big picture scheme of things.  Many project managers fail to use the appropriate and prescribed methods to determine whether or not a project should continue or be canceled.

Projects can typically start to run off course because the IT department feels they should be run … and should keep running.  If we only start IT projects that are deemed to have some value to the business — whether it’s legislative changes, support of a technology refresh or enhanced business functionality, then we as chief architects have a better chance at success.

Is it possible that it is purely the project perspective at fault for these dismal numbers? It may very well be as projects that just run on auto pilot.  Without a continual review of what the original business drivers were at the beginning, Architecture Governance audits, and the lack of concern that they continue to be on check may be the reason.  It is possible that a program or project portfolio approach would lead to success?

In performing a project portfolio exercise along side our architecture planning we align that business needs and business values with the projects that are described and put on the table.  Consider a review of each project with the perspective of ranking it against their counter-parts for pure business value and business drivers and need.  Would the chief archtiecthave a better chance to attack the projects that matter to us most each and every year and provide value time and again?  It’s worth a thought.

If we also use the enterprise architecture plan as a guide post as to which projects should emerge from IT, as well as from the strategy perspective the chief architect also has a better chance at crafting the best possible project portfolio for the upcoming year.  Is there a need for enterprise clarity on the value of IT to business?

I believe it absolutely is required.   We need to ensure that the business understands the value of bringing enterprise architects and leaders from the IT to the table when business decisions are made.

Often the chief architect or CIO knows where the IT or technology can be leveraged in order to gain competitive advantage.  We also know when the business strives to achieve something that may align with the project application package solution.  Business and IT strategies have been misaligned in the past.

Often the IT strategies are driven from the technology perspective only and things that we feel we would like to clean up, upgrade, play with or tinker with.   Instead, if we align the IT strategy with the business strategy each and every year the business shall receive something that they ask for and value.  At the end of our development work they will feel that IT has served them well.

This will greater our relationship with the business and their opinion of the IT professionals installed in our organization.  We need to architect in the ability to thrive on change.  Isn’t this really what the business truly asks for and needs on a continual basis?

We as chief architects need to architect out everything that inhibits change.  We need to be weary of this when we compromise our solutions and suggesting ideas and changes back to the business.   They should not even be on the suggestion table as we don’t want a business to fall in love with something that just has nothing but havoc wreaking in their future.

Get it done faster!  If you just can’t get started, there has got to be a better way.  I’d love to see more agile EA get done, so today I’ll share the most common and critical parts of an EA Plan.  Here is the checklist I use when creating plans for my clients and customers.

The Enterprise Architecture plan is a process as well as document set or repository that contains the written plans for the vision and development of the Enterprise Architecture.

There are many recommended components, of which many are included here. It is my recommendation that you consider creating a shell document/presentation with the following titles in order to keep the information you collect. As well, it can act as a quick guidepost for your endeavours.

1. Vision Statement including Strategy
2. Business Drivers & Goals for the Enterprise
3. Participants/Contributors in the Planning process
4. Leadership & Sponsorship
5. Guiding Principles
6. Approach & Strategy to the EAP
7. Current State Section
8. Target State Section
9. Transition Plan/Roadmap
10. Next steps/Issues/Outstanding

Way too long since the last post - mybad.  Too much book!

Sounds like a pretty sales-y headline, doesn’t it?  Well – I’ve got you reading and that was my attention.  It’s attention that you need to pay to your enterprise, your business or your organization.  Times are tough out there, and companies need you more than ever to demonstrate value, but also to roll up your sleeves and help to keep your company afloat.

There aren’t great job descriptions out there for Chief Architect’s.  To some companies, it’s head architect, top “smart guy/gal”, or even lead IT thinker.  You may be responsible for a very structured and detailed program, or you’ve been saddled with figuring out exactly what your job is.

Let me start by letting you in on three very important secrets that should be on your job description.  1. Risk.  2.  Risk   3.  Risk.

What do I mean?  Beyond everything else, you need to be your CIO’s eyes and ears when it comes to technology risk management from a really big picture perspective.  2009 is my year to focus on Perspective and the concept of dialing in and out on auto-focus as an architect.  The chief architect may be heads down in putting together an EA Program, Plan or Roadmap, but day to day work must be on their mind.

At any given moment, place and with any person in which you communicate, you need to be aware of the three biggest risks with respect to architecture in your company.    You don’t need to do any real work to create this list.  When you start with your company, use a default three, and each time you learn of something that has higher risk, move it to your list.

For example – if you have just started working at your company, your top three risks are
1.    No Disaster Recovery Plan
2.    Major Hardware failure in the gear that runs your most critical customer serving application
3.    No risk management system

As you get to know and learn about the systems, technology and data in your organization, you will be able to replace these incredibly general risks with those that are more specific.  If you’ve been there for any period of time, you may not have this list posted anywhere, but you can probably derive it in about 90 seconds.

Obviously, you need to find out if there is a DRP and know what it’s all about first.  After that, find out from the highest ranking technology architect or engineer that you can find what they feel the biggest infrastructure risk is.  Something else you might want to consider is the new category of risks that is similar to those that everyone talked about when “pandemic” was the big buzz word”.   Two words – supplier solvency.  With layoffs and shutdowns, is your DRP supplier afloat?

Finally – learn what the organizations plans, systems and methods are towards managing risk.    If there isn’t a system, documentation, plan or program, that just became your number one task.  Talk to your CIO.  Discuss with the IT staff in your company.  Demonstrate value in Architecture in another dimension – AVOIDING risk as a strategy.  Know when risk is discussed, where it’s documented and what the next steps are to manage or remove the risk.

As the Chief Architect, you should be your CIO’s trusted advisor.  As their trusted advisor, you need to both protect them, as well as look forward to their future.  Any future plans must include the removal of risk as well as creating great plans for the opportunities that exist.

Want more info on Enterprise Architecture?  Visit the portal

In my next posting, I’ll include the Big Three Secrets for planning and opportunities!

Happy Architecting
Sharon

It’s been far too long but I’m writing again - you see I’ve been writing a lot since I last wrote and so there are lots of pieces that should be appearing here soon - I’ll just have to figure out where to start.

I’ve been doing a lot of research lately on the resources available today on IT Architect Careers.  There isn’t much - a handful of books, a few websites and a couple of education offerings.  Career development has been a passion of mine for nearly 25 years - not sure why but I am fascinated to get a hold of the career section in the paper and have always been a go-to person when my colleagues and teams in architecture have been trying to decide what they might explore next.

I’ve decided it deserves to be in print and it’s been a work that’s been developing for nearly two years.  I finally have a name for this book that’s due from the publisher now April 28th, 2009 and it’s called “Architecting Your Career:  Build a Roadmap for Excellence in IT Architecture”.   It’s a partner to my architect career portal and so I’m so excited about it.

Here’s where you come in - I need to know the answer to this burning question as I’m trying to develop some bonus items for my book that will be accessible to those who buy it.  You can help by providing the answer to this one question.

Architect Abstract Ask Contest

At the end of the week, my assistant and I will draw the name for one who provide answers and they will win three free months membership on the career portal.  Deadline is February 28th, 2009

Happy Architecting!

Happy New Year

Here’s a quick post to announce some changes to our existing http://www.architectbootcamp.com site.  We’ve quietly launched a membership site that will enable our members to gain the knowledge and skills to become an excellent architect at a more rapid rate, and with less frustration and waiting.

For now, it’s a soft launch meaning there are still some bumps and bruises to be endured, but it will be great when it’s done, and a long time coming.  Membership login will be available shortly, so stay tuned for more info and links.

In the meantime, our blog has moved to www.architectbootcamp.net/blog, and we’ll provide updates to all of the links in the posts on this blog as soon as we can.

Have a very happy and safe new year in your part of the world, and join me in wishing others world peace, health and happiness in 2009!

Happy Architecting,

Sharon

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.

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!

Just a short one today - we’ll have other exciting news later on…

In the meantime, we’re getting into the swing of fall and “back to school” and our Architect Boot Camp classes are starting to fill.  If you haven’t already visited our training site, visit today and download our course catalog.   There is a full section on “how to decide” what type of architecture training is best for you in this catalog.

Deadlines for earlybird registration are fast approaching:

• Enterprise Architecture Boot Camp (EAB) - September 14, 2008 - Extended - September 19, 2008
• Business Architect Boot Camp (BAB) - September 23, 2008
• IT Architect Boot Camp (IAB) - September 22, 2008
• Solution Architect Boot Camp (SAB) - September 24, 2008

After these dates, registration fees return to normal, and classes that haven’t achieved their minimum registration will be rescheduled or cancelled.  If you are interested, but are just waiting approval let us know — each session we get calls for some of the workshops after the deadline dates indicating interest, and by then we’ve already made decisions to postpone or reschedule or even cancel classes.

If you aren’t sure - just give us a call at  204-488-2819 or leave us a comment about our training registration here.  Did you find it easy, more complicated, or about the same.