Thanks to Troux for a Great Event

George and I participated in the inaugural Troux Worldwide Conference two weeks ago in Austin, TX.  We felt that it was a wonderful collection of interesting speakers, spirited debate, and professionalism among peers.  While many events sponsored by a vendor can be dominated with tool demonstrations and sales presentations, Troux’s program was full of thought-provoking presentations from user case studies, to industry experts, to executive supporters.

Thanks to David Hood, Bertrand Hazard and the rest of Troux’s sales, events, and marketing staff for a truly professional, first class, worthwhile and downright fun event.  Looking forward to the next one!

EAA Views – Portfolio and Platform

As has been stated by EAdirections and others, Enteprise Application Architecture (EAA) is generally the second area of EA to mature, following the Enterprise Technology Architecture.  As the infrastructure is standardized, the EA team looks to the consumers of that infrastructure to take advantage of the standardization – the business systems. 

As organizations begin to address the EAA, they generally take two paths to maturity.  One addresses managing the complexity of the application portfolio, called the Portfolio View.  The other addresses managing the complexity of application Integration, which is called the Platform View.

Getting started with the Portfolio View involves a focus on identifying the gaps, weaknesses and overlaps in the set of applications the enterprise is currently operating, building and planning.  Our Jump Start matrices are one vehicle that you can use to help in this analysis.  Another early activity that we recommend is a quick “Business Fit Vs. Technical Fit” categorization of the current portfolio.  Going further than the current state assessment into gap analysis and roadmapping will require some basis for identifying future state aspects of the application portfolio.  We recommend Strategic Capabilities Changes analysis. 

Getting started with the Platform View involves designing standard integration methods and configurations of technology components to provide standard service capabilities (security, user interface, data interchange, directory, collaboration, etc.) to applications of similar technical types (packaged, BI, publishing, etc.).  Common steps to develop the platforms:

• Identify the needed platforms and capabilities
• Identify the needed services per platform
• Identify existing service providers –Including duplicates
• Declare standard (and alternate) service providers.  Use cases help when more than one alternative is available.
• Bundle services into Platform Configuration Document
• Identify missing services (no current provider)
• Identify candidate (and dependent) efforts to build platform service

One of the common practices among organizations maturing their EAA is collaboration between the EAA working group and the members of the ETA working group in the definition of platforms and platform services.

Common Step to Effectiveness – Alignment across EA Community

A common theme that seems to be coming up often lately with clients, prospects and some of the online forums I read is the gaps and overlaps that exist among the many groups involved in the EA function.  As EA becomes more effective, there tend to be more formalized groups created.  It is common for there to be a central EA team, but also working groups focused on one of more of the traditional domains of EA – business, information/data, application and technology.  

Who creates the standards?  Who decides where standards are needed?  Which teams should be involved in reviewing which projects and investment decisions?  Who models business processes?  These and many more questions will pop up as more and more groups, both formal and informal, get involved in the EA effort.  It is important to define the decision rights authority and areas of responsibility for each group.

Too many times, we see groups let these questions go unanswered and the result is as if EA no longer exists.  Instead of a coordinated, collaborative approach, the enterprise reverts back to several silos of decision makers who think they are contributing to EA.

While it is typical for the Core EA team to have a coordination role; as EA grows, this can become a monumental task as the EA Core Team is usually small and has other areas of responsibility.  So our recommendation is to document the areas of responsibility for each team involved, including non-architecture groups such as application development, infrastructure engineering, database management or IT operations, as well as the decision rights authority for each group as well. 

On a related topic, check out George’s blog entry on Who Decides?

Call to Action – Help the Online Forums Get EA Right!

Anyone else a little frustrated with the techno-oriented positioning of many of the questions and postings on EA forums?  I understand that most of us are Information Technology (IT) professionals, so it is a good source of professionals with information and experience on technology topics.  However, as we have noted many times, it is this positioning reinforcement that continues to confuse many who are new to the practice about the intended nature of EA.

While there has been some lively debate over the last year or so about the true nature and placement of Enterprise Business Architecture, there has been some relatively consistent positioning of EA over the last decade as a strategic planning discipline.  EA is positioned as a discipline (both the process, people and resulting artifacts) intended to define a long-term, business driven future state to help decision makers rationalize short term needs with long-term direction. 

Please join us in trying to be consistent in the positioning of EA.

Business Architecture Discussions Continues with The Open Group Seattle Conference

Last year I mentioned that I attended The Open Group Architecture Practitioners Conference In Toronto and that I was very excited about the direction that the conversations went – namely the need for EA to become more of a strategic business discipline.  This month, I attended the version of this event in Seattle.  Again, I was encouraged.  This time by the theme moving past need and into practice.  The plenary sessions, which are the general sessions that are open to Open Group members and non-members alike, all focused on moving EA away from IT and towards the business.  With titles like “Changing the Conversation” and “The Language of Business Architecture” it is obvious that the conference tried to get people to think differently.  Some of the side tracks also promoted this concept, such as “Business Driven SOA,” “Translating Business Speak into IT Speak” and “Presenting EA to C-Level and The Board.”  Hopefully, they will continue and others will follow. 

My presentation was part of the “Language of Business Architecture” session, focusing on the dynamics and language of Business Architecture as it evolves from a commonly-accepted, but scarcely-executed domain of EA into a necessary part of a compelling and successful business transformation effort.  The presentation is available here. 

Also, following my presentation, Dana Gardner of Interarbor Solutions interviewed me for the BriefingsDirect series.  The topic of the conversation centered around the points that I made during my presentation on the language of business architecture, relaying the effectives ways that organizations can become successful in the development of transformational enterprise business architecture.

Click here to listen to the podcast.

Click here to read the transcript.

Architecture Readiness? What is that?

Recently I saw a question posted on a popular EA forum, asking about detecting the “architecture readiness” of the poster’s organization.   That got me to thinking about what we mean about “readiness” and is it that relevant anymore.  I admit that in the mid-90′s we would discuss the notion of an organizations readiness to embrace EA, but my perspective has changed drastically.  I think that the question is no longer “Is my organization ready to embrace and support EA?” but rather “How can I be effective in utilizing an EA approach in my organization?”  Clearly, the issues demanding EA support are still prevalent and the maturity of EA as a discipline has increased during the time since the mid-90′s. 

I do not believe that any EA function can be diagnosed quickly, as most of the issues regarding “readiness” are probably a unique combination within a company.  It starts with identifying the leverageable strengths, obstacles to overcome, and methods of mitigating those obstacles – including awareness at the executive level.  I don’t believe that any organization is completely “unready” for EA, but there are certain factors that are a quick read into how long it will take for EA to be a valuable, recognized formal method of helping the organization plan, rather than just a glorified design standards group.  Key among those factors is the understanding of and desire for EA as a strategic planning discipline by the CIO first, and the rest of EA management, second.  Many times, it helps to build some of the context level artifacts BEFORE you attempt to build executive awareness as those artifacts can be a very powerful part of the argument.  There are other activities (communication, collaboration, process integration, separating and defining roles and responsibilities among different architecture levels, and governance to name the most important) that all work together to establish a culture of EA – which is really what we are talking about here.

Getting Started with EIA – Identify High Level Information Classes

Recently, we have discussed the HL classes for Business Archtiecture (functions, processes, services) and Application Architecture (application classes and platforms) and Technology Architecture (domains and components).  Now let’s turn to Information Architecture, not Data Architecture.

In order to get started with Information Architecture, you need to identify all of the major “things” that your business produces or acquires information about.  We will call these information classes.  They are not databases or objects or  attributes.  They are conceptual in nature, but they represent the major entities that your enterprise requires information about.  These typically include entities such as customer, supplier, product or service, orders, items, employees, facilities, and inventory.  Of course, each enterprise may have their own language.  For instance, a financial services company may call their products by a different name, such as policy or account or fund.  And public sector organizations may not use the term customers, but rather citizens, constituents or voters.  And those in the healthcare related businesses would say patients.  In any case, you are primarily concerned with the group of people the enterprise is providing a service or product to, the sources of those products, and the major entitities involved in the production, stocking, logistics, ordering and delivery of said product or service.  You may have subclasses, as well, but for the purposes of getting started, we suggest no more than one level of decomposition.

Once the High Level Information Classes have been identified, they become more meaningful to EA work once you map them to the functional heirarchy and application classes. For more information and examples related to this type of information mapping, please see our Jump Start materials.

Edmonton – Larry DeBoever speaks about Trends at CIPS ICE 2009

Larry DeBoever will be speaking November 4th in Edmonton at the CIPS ICE 2009 Conference.

Business & Technology Trends That Will Drive Transformation 2010-2012: A Few Big Predictions and a Much Smaller Survival Guide

We are entering a period of profound transformation that is being driven by significant advancements in information technology and the rapidly changing economics of technology. The enormous implications of these emerging capabilities upon the way organizations do their work, the solutions we implement to enable the business, and the underlying technologies are not well understood by executive leadership, IT professionals and the security community. In this entertaining and insightful discussion, Larry DeBoever describes several key technology trends, the underlying ‘tech-tonics’ (the economics of technology) that will accelerate their adoption, and their potential impact upon business, government, education the family, and IT professionals.

Topics include:

• What big vendors know that you don’t
• Three technology trends that really scare me
• five rules for separating real trends from techno-fads
• A six-part Survival Guide. What your IT organization needs to do NOW to stand a chance

My Takeaways from the 23rd TOGAF Practitioners Conference

I attended the 23rd TOGAF Practitioners Conference last week in Toronto, where I was invited to speak on a panel (podcast coming soon on ZDNET) entitled “Architecture’s Scope Extends Beyond the Enterprise.” I had never been to a TOGAF event, so I was looking forward to seeing what the event would be like. I am happy to say that I was not disappointed with my decision to attend. The Open Group were gracious hosts. The attendees more varied in levels of experience than I had anticipated. Many of the presentations and panels were not framework oriented or TOGAF oriented, making for a more well-rounded EA conference that would have benefitted organizations that use TOGAF very little or not at all. But my greatest takeaway from the event was the underlying theme that ran through the keynotes, breakouts, panels, Q&A sessions and hallway conversations – It is time for EA to become a more strategic BUSINESS discipline. For those of you familiar with EAdirections and our time with the META Group, this is not a new message. However, it is refreshing to see a group perceived as heavily IT-focused as The Open Group to promote this message through the non-member and member speakers alike, as well as some of the tracks in the program. Here are some examples:

• The panel I sat on, while entitled “Architecture’s Scope Extends Beyond the Enterprise,” was actually focused on how the role of EA might be evolving in the future. The moderator and audience questioned the ability of EA to reach its potential as an effort within the IT department. While most see that EA has expanded beyond technology architecture, the evolution of EA towards business architecture is just beginning, if at all, in most organizations.

• The afternoon of day 1 featured tracks on “Holistic EA and and the Role of Business” and “EA Implementation and Business Transformation.”

• One of the afternoon speakers, Bill Sheleg of Deloitte, spoke on the topic of “Extending EA to a Business Discipline.” His premise, as we have expressed for years, is that there is a disconnect in many organizations between the defined strategy and the activities that are going on in and organizations, and that EA is uniquely positioned to bridge that gap. One of the key points he made came from a Bain Consulting study, which said “Seven out of eight companies in a global sample of 1,854 large corporations failed to achieve profitable growth, though more than 90 percent had detailed strategic plans ….”

• The highlight of day 1 for me was the end of day roundtable discussion. All of the speakers from the morning panel and the afternoon speakers in the Holistic EA track joined with the audience to share ideas and thoughts on the question: “What’s next for EA?” The resounding consensus of the group discussion was that EA needs to become a tool that the business (not just IT) uses to improve the execution of strategy. How that will happen, however, brought up several different opinions from the group.

• The second day featured an entire track on the role and profession of business analysis and the parallels between business analysis and business architecture. This track was highlighted by a discussion from Kathleen Barrett, President of the International Institute of Business Analysts (IIBA). She spoke on the evolution of the profession of business analysts, going so far as to say that the set of skills and knowledge that business analysts possess are the same as business architects should possess. IIBA just published the Business Analyst Book of Knowledge (BABOK) 2.0, which is something that I would recommend aspiring BA’s (analyst or architect) make a part of their repertoire.

The next TOGAF conference in North America will be in early 2010 in Seattle, WA, where I hope to see that conversation has continued and evolved.

Another interesting speaker was David Foote, of Foote Partners (www.footepartners.com), a research company focused on IT workforce management and compensation practices, trends and issues. David provided quite a bit of interesting data and research conclusions regarding IT jobs, skills and certifications in the US and Canada. His latest press release is available at www.tinyurl.com/ltfpte, containing much of the information he shared with us, but there were three salient points that I want to share:

1 – Although the US unemployment rate is still growing, there are some segments of IT that are losing jobs at a slower rate than most other segments, and in some cases, even gaining jobs in some months. This counter trending is typical of the IT profession in a recession due to the increased dependency on IT.

2 – One of the areas in which David sees a difference in this recession, than in past recessions, is that companies are being very careful about where they cut jobs, so that when the economy begins to rebound, they will be ready with their best people. Specifically, IT professionals with architecture skills and certifications are being valued very highly.

3 – To further solidify the position of architects, including enterprise architects, David presented several data points that show that while many IT skills and certifications are losing value with employers, those of architects are generally trending upward. For instance, Architecture and Project Management certifications that are tracked by Foote Partners have actually increased in value by 4.3% during Q2 2009, one of only 3 areas with growth. Also, of the 19 architecture certifications that they track, none have lost value in the last quarter, with some even gaining value.

Taken altogether, David did a pretty good job of convincing the audience that while some analysts may have predicted a “Death Knell” for Enterprise Architecture in 2009, that does not appear to be the case. My colleague George Paras also disputed this notion in a recent blog entry, www.eadirections.wordpress.com/2009/03/17/will-ea-groups-disappear-in-2009/. Both the data and David’s conversations with executives support the notion that this recession is a great opportunity for IT professionals with architecture skills to thrive.