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.

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

Want the rest of this article - see the full report.

Part 3 of a 5 part series on Promoting EA

Ever ask a CIO “What keeps you up at night?”  If you asked the same question to your CEO, their top 5 initiatives are pretty much all he thinks about from morning til night.

You can bet that at least four of them impact bottom line or share price.   If the CEO’s top five are financially driven, you can bet that the CIO’s initiatives and forethoughts will match.  Using a little information economics, the principal drivers of your sales plan, your search for support had better be underlined in value, as that is almost all he or she will be thinking about as you propose or promote your program.  Ensure that the shortest form of your elevator speech = value!

Most CEO’s would prefer to focus on how they can get more value out of what they already have.  They are also really interested in what they can spend less money on.  Finally, they are very intrigued by anything that shows in a compelling manner how they might reduce the risk of their investment in information technology strategies.

Here’s where we come in.  Architecture initiatives in both the public and private sectors have typically had a poor record of success.  Frequently we have seen more restarts than fresh starts.  The impediments have been of two types: technical (products and methods) and cultural. The industry has made substantial progress in overcoming the technical barriers. However, for most organizations, the cultural obstacles have become much more significant.

It is also difficult as we are focused on long term future initiatives and showing the returns later in the cycle.   We’ve often tried selling to the wrong customer, and selling the wrong “product”.  There is perceived high risk of implementation.

The business sees that current systems do not meet critical business requirements and lack flexibility to adapt to changing business needs.  It is difficult to quantify benefits of deploying technology.  What is typically forefront in the memory of those who pay the bills is deployment for the sake of technology.  We’ve seen so many of our current systems developed “ad-hoc” and the lack of organized planning lead to higher operating costs and duplication of effort.  There has frequently been an unacceptable speed of delivery which most likely caused negative effects on time to market.

So - What Do We Do?

We need to ensure that architecture is business driven.  We need a strategy to create and communicate our plans and the benefits.   Get all the details on creating this strategy.   If you want to know how to make these  efforts work at your organization, see our training schedule.

Happy Architecting!

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

Monday is as good as any to do something new.  For most, above average.  Well - today I figured I’d **make** the time to move this blog to the Architect Boot Camp site.  Here it is - hope you benefit from it and I do have plans (hopes) to post much more regularly.

What’s new?  I’ve been really busy getting the fall 2008-09 Architect Boot Camp Workshop schedule completed, as well as some drafts on my book and the course ware updated.  I’ve gone with a new set of lab exercises, as well as a lot of more up to date content.  After a recent speech at the Open Group Enterprise Architecture Conference, in Chicago in July, I felt that a more expansive section on TOGAF was warranted.

As well, the Firefli Web Site has been updated with a new blog format, so that I have a hope (and a prayer) of keeping these things up to date!

Upcoming events are detailed on both the Architect Boot Camp site, as well as Firefli.  I will be giving a speech “Good To Great – Paving the Road to Excellence for the Enterprise Architect”at the upcoming Enterprise Architecture Conference, provided by IIR.  More details as they are posted on their site.

Happy Architecting!

Sharon

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!

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.

Happy New Year! It’s nice to be back again and writing about my favorite topic.

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!

Does it ever seem that as an Enterprise Architect, we have many dragons to slay? Our organizations confuse the Chief Architect with chief technology problem solver, and it isn’t their fault. Often the current technology hot spot of the day is something that lives in the EA realm, and we are the captain of the ship.

We’ve had many metaphors - the Builder, the Architect of a house, the City Planner, or perhaps the Pilot of an airplane or ship (thanks Mr. Zachman!). Here is mine:

An organization, when embarking on an EA program, needs a cook. They need to mix some things up to create a tantalizing dish. There is not often one recipe, but several that might suit the ingredients you have at hand. At some point, depending on the size of the organization, you may find that there are too many cooks in the kitchen, and a chef de maison, or Head Chef is required. The chef will prepare the menu, and ensure that the restaurant has the ingredients at hand.

What the cooks do to add flavor and seasoning may be their choice, or it may be strictly regulated. The McDonalds restaurant does much to ensure that their food tastes the same each and every time. Some restaurants to do - these are not chains, but individual “spots” for a bite out.

Sometimes, there are too many cooks in the kitchen. As of late, I’ve seen several folks try their hand at mixing and matching SDLC’s. The chief architect may or not get involved from a standards perspective, or from a governance and compliance issue with respect to artifacts. There is no “right” SDLC. The facts are simple - too many cooks will ruin the soup - too many flavors will confuse the issue.

One recipe may be selected for the best “dish of the house”. There is room to decide whether the head chef is creating the meal depending on the appetite. If there is appetite for chateau briande, so be it. The SDLC will be complex with many options. If there is only appetite for deli or fast food, or perhaps even the corner restaurant that sells burgers and fries, the SDLC must be simple with few key artifacts and simple methods.

Chefs - the choice is yours. Remember, if there are too many cooks in the kitchen, there will be a fire!

Happy Architecting.