There aren’t great job descriptions out there for Chief Architect’s.  To some companies, it’s head architect, top “smart guy/gal”, “IT Strategist” 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.  Their trusted advisor.  2009 is my year to focus on Perspective and the concept of dialing in and out on auto-focus as an architect.  Zooming In as a matter of fact.  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.

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

Happy Architecting

The Enterprise Information Architecture is the center most intersection of this diagram.

This is where all high-level planning activities and artifacts are created.

The three domains – Business, Users and Organization contribute data and context to the activities.

* Users: (who they are, what their information-seeking behaviors and needs are)
* Content: (volume, formats, metadata, structure, organization)
* Context: (business model, business value, politics, culture, resources and resource constraints)

“By 2008, 40% of enterprise architects will have primary expertise in business strategy or process engineering” 2004 Meta Group, Inc.

They get it. It took some time, but they get it now. I might generalize and say that most medium size businesses have some sort of architecture function in their midst. I’d go further an say every large business now believes that architecture is the brass ring as far as IT success is concerned.

Why is that? Some might argue that that SOX and Clinger-Cohen in the United States have enacted regulations that force this issue. Others might just say that the world has become technical enough to demand it. Or, we’ve got enough airplane magazines now that use the word.

Let’s be optimistic here – we, as IT professionals finally get it, and that is why. What do we get? That Business drives IT. Period. End of sentence. Business strategy drives enterprise architecture, and business is the pure and simple reason that IT exists in the first place. Enterprise architecture success is determined by corporate and line-of-business managers support.

We have started to group our IT product catalog around services. We have application, technology and operational service portfolios that contact web products such as applications, frameworks, web and internet hosting, as well as customer support. Components are groups into services in each portfolio rather than around business applications.

We are starting to understand leverage and reuse. We are getting a spot at the dinner table when the family discusses business strategy. If we are complete, we will ensure that we have some definition within our IT house walls, of the organization’s environment, its goals, objectives, major programs of action and the resource allocation choices required to execute them.

We seem to understand integration…

An integrated strategy which includes technology is enabling businesses to gain successes as never seen before. When we listen to what the business is trying to achieve, and find ways to enable their desires through technology and they can see it, we are viewed as both compliant and successful. If we are to show up at the dinner table and talk only about new cool technologies, our stock continues to tumble.

Business Executives always go back to the basics when considering strategies. They look at perspectives such as product differentiation and marketing segmentation when considering new strategies. If we can enable them to reach new levels with the use of technology, and speak to how we can help them to arrive at these goals in their terms, they understand, accept and encourage us.

Learn Business Speak

We, as enterprise architects, need to truly understand more business speak. If you are the architect in a commercial setting, take the time to understand some basics. For example, market factors are an excellent area of business knowledge worth knowing. If you spend as some time this month researching various marketing factors such as market entry, product risk, product differentiation and product price positioning in relation to the types of technologies that might be required to implement such strategies, you will have well spent your reading and research time.

I would suggest you spend some time looking at various business decision making techniques, such as Boston Consulting Group’s Product Portfolio Analysis and Porter’s Five Forces Analysis. I’ve spent time studying and using many such models and techniques when I’ve both analyzed and modeled business architectures and share some of this information at my decision making site.

Strategic planning considers business strategic value of IT investments. Learning business strategy yourself will payoff in spades to your future. It is something that may not interest you in theory initially, but when you understand how it relates to technology, you might become much more interested and your stake value will increase dramatically!

– A reprint of an Architect Abstract newsletter article

It was fabulous to see the look on her face when I explained that there had been many talks to integrate with such a service, and since the decision had been not to, it was not lost. You see, there were business implications in integrating the service, and while the business did not dismiss the objective as impossible, they said “just not right now”.

We have to include design for such possibilities, even if we don’t have all the plumbing installed at the time.

It’s an exciting time in both Enterprise Architecture and IT architecture in general, as SOA continues to build momentum and gain respect as more than a silver bullet.

I cover the topic Service Oriented Architecture extensively in both the Enterprise Architecture Boot Camp, as well as an upcoming one day workshop “The Service Oriented Architecture Boot Camp”. For more information, see the training catalogue.

Give the Business What They Want!

Last week as I was shuffling my IT magazine pile looking for something good to read, I came across an editor’s note in EDGE Magazine that validated something that I’d worked on very recently. As enterprise architect’s, we are always trying to be validated, justify our projects and sustain funding for the next wave of what we hope to be the path to goodness.

The article stated “Ask any CEO to name the very top items on their agenda and the conversation invariably turns to “innovation” and “transformation”. As any CIO to name their very top things on their list and they will tell you its “information” and “technology.” “

Previously I ran a workshop at a PMI conference called “Optimizing the Program Portfolio” that reinforced some of these same beliefs. The crux of it all was that if we were to carefully plan and plot our course of programs with both our assets and proposed projects in mind, we should maximize efficiencies reducing budget and time resources spent on running the business. This in turn, would make more time for transforming the business.

It seems like a simple feat, but this is more complicated than one would think. Program Management and Enterprise Architecture are so very deeply intertwined that one should hardly talk about one without the other. It seems that we never get past choosing a framework, cobbling together a strategy and then completing the first few models and maybe a set of principles. Beyond all of this is planning for transition.

There will be so many projects that need to be planned and executed in order to get an actionable enterprise architecture, that we will likely be overwhelmed and unable to get even the smallest percentage done because of ongoing operational and infrastructure support projects. It is important that we carefully time and plan what will happen next so that in the end we are making more time for the things that CEO’s have on the top of their lists.

Often we do our CEO’s top priority, but at the expense of our operational needs. We are in a rush to bring in silver bullet solutions, excess resources, and cut in-progress projects because they aren’t on the top of the list. Sometimes, we need to push back, ever so slightly on timing only to ensure that the infrastructure and architecture can support these transitional projects.

On the other hand, we need to expedite these projects, and keeping an eye on our top priority has become easier now that we have the attention of most in the organization. Services oriented architecture is most likely not just flavor of the day, and we are apt to find support for infrastructure and architecture projects that will support it.

So where does the portfolio management story fit in? We must take a look at our top three priorities both from an IT perspective as well as a corporate view, and determine the best ordering. We should look at what we have (our assets), leverage them as best we can, and then view our gaps and projects on the books to come up with a portfolio that will make both the CEO and CIO smile.