I’m not exactly sure how this happened, but they have asked me to speak again (must be desperate for content). My session is at 9am on Friday and is called “Selling the Value of Enterprise Architecture to the CxO”. I’ll upload the deck here when the session is complete for those that can’t make it. It should be interesting. I’ve done this session once before for internal Microsoft event and it was well received – we’ll see how it resonates with this audience.

For more information NWA TechFest.

This morning’s repost took on this flavor

Here’s a great thread, triggered by a Gartner blog (Business Architecture is Part of Enterprise Architecture), about what Business Architecture is – and is not – and how it relates to Enterprise Architecture. One of the comments from Clifford Berg:

“The IT-originated frameworks are generally about the production of a bunch of very complex and time consuming documents and diagrams. There is a focus on creating these rather than identifying and addressing issues. For this reason I think they result in a massive waste of energy and time, and serve to sideline IT because no one in the business knows what these diagrams are or cares about them. They do not enhance communication with the business.”

I really like that one: If Enterprise Architecture, as a discipline, drives itself towards irrelevancy – then this is the key reason why.

Another nice comment from Matthew De George’s related blog: “Because of this history, I believe business architecture has currently been defined, unintentionally, to only solve the problem of failed software development projects.” Which statement, to my opinion, should also be expanded to include failed LOB application deployment projects.

I’m of the opinion that until Enterprise Architecture is truly embraced by the entire Enterprise it will continue it’s path to irrelevance.  That it is the Enterprise Architect’s job – not just solve IT issues or describe IT to the business (i.e. practicing “business architecture” or “infrastructure architecture”) – but rather to help define the appropriate primitives and composites upon which the entire organization is built. 

Thank you IT for forcing this kind of thinking, no thanks for thinking that it was only valuable for technology problems.

This seems to me a bad idea for everyone involved.  For Microsoft, this simply extends the support issues and expectations of our customers for another 10 years!  For IT departments, this continues to put them behind and losing credibility to their business customers.  With nearly 150 million licenses of Windows 7 already in the marketplace, business users (and IT people for sure) are going to outpace the technology in their homes well before the IT department catches up.

Microsoft says 74 percent of work PCs still use Windows XP, extends downgrade rights until 2020 – Engadget

IASA – The landing page for the Internal Association of Software Architects.

Evaluating Education and Certification for Architects

In the session I suggested a few reading materials.

Building Better Business Cases for IT – this is a paper written by the Crannfield School of Business which goes into much more detail on building benefit dependency networks which I discussed in this session.

Made to Stick – this book shows how to make your message stick.  Architecture is about communicating upward (business and tech decision makers) and downward (to engineers).  This book provides many, many examples of how to create an impactful message.

Here’s a few other links that I think are interesting and relevant to enterprise architecture

Enterprise Architecture on MSDN

Microsoft Business Architecture (MSBA) formerly Motion

Here’s my take.

EA “dying” is probably too ominous a prophecy. The reality is that because EA is not well defined (primarily in scope and vision) all of the summary questions below become relevant.

In organizations where EA is well-defined (specific scope, clear expectations, and measurable accountability), I think companies have seen a positive advantage of having such an organization. In my mind, having a small EA organization helps to promote consistency and elimination of redundant solutions (which is the best reason to have an EA). What too often happens with small EA orgs though is that this group becomes a funnel through which major IT decisions must flow, contact with the business is forced and/or solutions must be vetted. An EA shouldn’t consist of the elder statesmen of the organization through which all tribal knowledge must flow. On the other hand, when an EA org is too big, then knowledge sharing, consistent practices and redundancy become concerns – in which case you are probably better off not having any EA at all.

So, is EA dying? I hope so, if it does then the next version of ensuring consistency in enterprise solutions, buying decisions and influence of IT on business productivity can take hold. Natural selection will ensure that the best practices live on by whatever name, while those that practice EA in the most effective manner will continue to be called on to keep IT and business customers communicating effectively.

Although I won’t reveal the status of any of the candidates or their names, I would like to point out some of the qualities that were important to me as I considered each candidate’s presentation, experience and qualification.  I share this information because I would have liked to have more insight into what the board was looking for as I prepared for my MCA certification and also the CITA-P board.  I’m not the definitive source of what you will find at your board, but I hope to give you some insight into where you should prepare and what was important to me.

Communication / Presentation

This seems like the most logical place to start.  I mean after walking in the room, the first thing that happens (after introductions) is that you present for 30 minutes.  Use your time wisely!  Here’s a couple of hints.

• Respect the board.  You have put a ton of work into your presentation (probably in excess of 80 hours!).  The members of the board put in the same effort into their presentations, CV and assessments – plus they read yours, put time into thoughtful questions and may have traveled to give you invaluable career advice.  Keep this in mind.  The board has done everything you have been asked to do and more.
• Dress appropriately.  You can always take off a jacket or put a tie in your pocket if it’s too overdressed, but you can’t poof a tie or jacket out of your ass if someone on the board is dressed more formally than you.
• Please stand up.  I can’t think of very many amazing speeches that have been delivered from a chair.  Unless you have a physical handicap, please stand.  You will command more respect.  You’ll keep my attention and I’ll be much more interested in what you have to say.  (This is just me I’m sure, others probably prefer you be comfortable).  If you stand, then you can easily move to stand in front of your interviewer to answer questions which is much more engaging that speaking loudly across a long table or room.
• Keep the information on the slides to a minimum.  I want to hear the story from you, not read your deck.  Put notes on the slides and then tell me the story that ties all the notes together.  DO NOT READ TO ME.  I don’t want to read your 200 word slide in 10 pt font, I already read your paper – tell me the story.
• Keep the background short.  I don’t care about your very first job out of school – unless you did something very unique.  Tell me how you became an architect – skip the trivia and get to the meat of the matter.  I’ve already read your resume – if I have a question I’ll ask.  Assume that I know who you are.  If you must share a background slide – make it quick and memorable.  Don’t confuse me with irrelevant data.  I don’t care where you got your degree, when you got your degree or that you washed cars to pay for college.
• Tell a story I can remember.  I’ve talked about this alot in other posts (here, here).  Architects are story tellers.  They tell stories to business users to describe what they are going to get for their investment.  They tell stories to engineers so that engineers can extrapolate the ideas to fill the holes.  Tell me a story in your presentation.  Don’t go through a checklist.  Give me the story arc.  Every good story has a beginning, middle, and end.  Some conflict – which should be resolved.  This kind of a story helps me to fill in the gaps in your experience and gives us a shared experience to discuss in our 20 minutes of interview time.

Experience and Qualifications

When I review a candidates experiences and qualifications, I really press to understand that the candidate can speak in business terms and in technical terms.  Here are a few things I’m looking to see through your submission, presentation and interview. 

• Documentation.  I tend to use the documentation a candidate has submitted only for a guide.  I like to probe areas that are rated highly or lowly.  To this extent, do not try to snow me.  The board of peers will figure out whether you are blowing smoke or whether you know your stuff.
• Can you speak to a business customer?  Show me that you can evaluate a business request, determine the requirements for a solution and perform translation between technical people and business people.  If you can find the functional requirements are you able to figure out why these requirements are so?  Can you help a customer prioritize their investments (i.e. how do you qualify which features make it into each release)?
• Are you experiences repeatable?  If you a Solution Architect in the US working primarily in the financial services industry, how will you assure me (and the board) that you can be just as successful as an SA working in Europe for an Oil and Gas company?  Show me this repeatability by sharing common techniques and strategies.  Charisma is not enough.  Your experience is not enough to carry you in every situation.  Which tools do you use to understand the industry, evaluate the business, and navigate the politics in the new organization.
• How have you used architecture to influence business decisions?  The feedback loop between architecture and business process is why architecture is valuable (this probably requires another post).  As a professional, practicing architecture, you likely see many business processes.  By applying an architecture is there a way to improve the process (not just through automation, but by removing or combining steps)?

I probably should go on to discuss the topics and what I look for in each one.  If there is enough interest, I’ll drill into this a bit deeper.

There are many successful organizations that have grown and thrived without ever creating or maintaining an enterprise architecture.  And I would argue until recently, say the last 5 years or less, most organizations never really took enterprise architecture seriously.  What changed in these organizations and the world to make enterprise architecture such a necessity?  I think there has been at least one fundamental change – the global economic recession.

With companies looking to maximize all of their investments, reduce inventory, improve efficiency in their workforce they have begun to focus on one of the biggest cost centers in their entire support business – the IT department.  In many places the IT department is has become a costly support organization, providing essential services such as desktops for information workers and networks to enable communications and collaboration.  Within the last 10 years, companies have also come to discover that without an on-line presence they are lagging behind their competition.  Building and maintaining this on-line communication channel with customers and suppliers is costly and usually falls into the IT budget.

To reduce the cost of the IT organization, there has been a two pronged approach.  First, put the business in charge of the IT budget – require business units to fund IT projects out of an operating budget.  Secondly, require IT to identify and implement cost-savings measures within the organization.  Clearly, not all organizations have implemented both of these measures completely or consistently.  Although these are two major trends which are helping to drive down the cost of IT.  Each organization needs to figure out what the proper balance of these two approaches will yield the best results.

Putting the business units in charge of the IT budget.  Funding projects directly and paying for support on an as-needed basis, seems at first glance a very mature approach to getting control over IT spend.  What tends to happen in many cases is that business units can get what feels like better service from an external vendor by outsourcing projects or making buying decisions without involving the IT organization.  Sometimes this works well.  Most times the business units find that the cheaper cost comes from decreased quality or lack of support from these external technology solution providers.  Business units soon find out that paying for support and project management in some form, tends to increase the reliability of the solution in the end.  (See my post I’m not paying for that! for more on that topic).

The second prong is holding IT accountable for reducing cost on its own.  There are a few things that happen here, first the IT group looks at it’s expenses and realizes that it – like nearly all businesses – spends a majority of it’s operating budget on labor costs.  The most immediate solution then is to figure out where to cut positions and force efficiency improvements.  Second, it looks to improve efficiency by hiring cheaper labor or using off-shore service providers.  Both of these approaches have merit and tend to meet the desired outcome of reduced labor costs and lower operating expenses.  But this is only sustainable for a short time.  It isn’t possible to continue to cut your workforce and eventually the cost of off-shoring or outsourcing your IT department will grow as demand outpaces supply.

To improve efficiency further, I suggest this is when an EA becomes mandatory.  A useful EA will provide a view of the business/technology interaction that can improve efficiency by identifying redundant solutions, highlight common problems and show valuable inconsistencies that can lead to process improvements.

Look around you, how many people do you work with today that you have worked with before either in a different role in the same company or with another company.  I’m often reminded that my co-worker today may be my customer tomorrow.  In an extreme example, when I was working for a very large company with a multi-billion dollar IT organization, one of the vendors I regularly interacted with was NCR.  I was responsible for UNIX systems and I would have to call them at least weekly to have them provide support, fix a customer satisfaction issue and sometimes negotiate for services/hardware.  Since my company was a major customer for NCR, I enjoyed alot of power as a Systems Engineer.  I was able to demand quick response times, dictate how solutions would be delivered and even require escalations.  Fortunately, I was usually on my best behavior with this vendor (others not so much).  After three years, one of my primary contacts came to work for my current employer and went from being my servant to being my skip-level director!

Instead I have settled on the topic “I’m not paying for that!”.  In this session, I plan to look at those aspects of a project which are required for it’s success, but to which your business doesn’t feel are necessary.  Things like – project management, architecture and documentation and the dreaded cost of maintenance and stabilization.

In each one of these cases the issue is not necessarily the idea of these things.  Who doesn’t want their project to be managed so that it finishes on time?  Why wouldn’t you want the service plan which ensures this expensive solution continues to run well into the future?  The central issue is that we, as a profession, have shown no these investments to have no material impact on the execution of the solution.  Nearly 80% of all software projects are late and over budget!  Is this because 80% have no project management?  I think not.  I think it is that because of poor planning and the ineffectiveness to plan and execute a project plan that these projects are too expensive.

Have we shown that spending $30/GB leads to more reliable solutions than the $100/TB that business customers are putting on their PCs at home?  We have proved this to ourselves and our own IT brethren, but it is up to us seasoned professionals – the architects that know how to speak the language of business and technology – to make the case the business.  Speaking their language, explaining and proving that the $30 a GB disk is worth the premium.  It is also incumbent on us architects to listen to our customers and communicate what is valuable to them back to our engineering teams.  Maybe that SharePoint site that hosts pictures from the company picnic doesn’t need to have RAID 1 / SAN attached / disaster recovery.  Maybe we can afford to offer a less expensive alternative with a less stringent SLA.

And so I ask you – what is it that your customer won’t pay for?  And what have you done to justify the cost or negotiate a different solution?