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!

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!

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.

Ok - so maybe you haven’t heard the buzz about the marriage between EA and Portfolio Management. It’s been going on long enough to get the seven year itch already - so why should I go on about that today?

My head hurts - I’ve been knee deep in the weeds building courseware for about three months and I’ve come up for air. It’s probably the first thing I thought of because I was digging up some articles for a participant in a workshop that was in need of more info on the topic. Or maybe it was because I was drawing diagrams all night and when I was done I couldn’t remember if the diagram was going into an article for a Project Management piece on Portfolio Management or an Enterprise Architecture.

To make a long story short - they are the same Portfolio Management. Different constituencies might care for different reasons, but at the end of the day, the same portfolio should be planned. Granted - if the Enterprise Architect gets their way - there will be the project completed that gives him or her the best new models to add to their collection - isn’t that what everyone thinks we do? Or is it picking the standards that everyone has to follow????

Actually - it will fill a gap from the charts on the analysis task of the most recent EA program review. And - it will match up to the latest and greatest business initiatives sadly lacking archtitecture. What difference does it make? The EA’s and PM’s need to work together, and other than a few squabbles about scope - aren’t they fighting the same battles? To get sorely needed projects done with precious few budget dollars?

Another thought on the subject - the project manager and the program or portfolio manager are fighting different battles. The project manager wants to get the project done as directed, with as little risk and variance on budget as possible, with the best use of resources as possible.

The EA wants to get the right things done, and usually budget is the last thing on their list, other than the fact that they don’t want their EA program shut down. So - we’ll all have to get along here. We want to do the right things, ones in the best proportion to keeping the business running, getting the optimal amount of growth in the organization, and transforming that organization to meet strategic needs of the executives and planners.

At the final outcome, both parties will be happy if they solved a business requirement, met an organizational objective and ok, created a few models along the way. Is that so bad?

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