April 4, 2011
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!
April 30, 2010
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.
April 30, 2010
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?
April 30, 2010
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.
February 28, 2010
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.
December 1, 2009
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.
September 30, 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.
- 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