|
EAdirections Blog
EAdirections is a relationship-based advisory services firm focused on improving the effectiveness of EA teams, IT leaders, and business executives. Our managing directors are world-renowned experts in the discipline of enterprise architecture. With over 50 years of combined experience as consultants, analysts, and enterprise architects, we are uniquely positioned to deliver world-class support to your Enterprise Architecture efforts. New Vectors Newsletter Format
Monday, June 22 2009
You have recently been telling us that our newsletters are a bit long. One quote was "Too much scrolling!" We hear you. Your comments on content have always been enthusiastic, not so much on format. We have responded to your suggestions for a more compact, efficient digest-style format. Please send us your comments on the new layout. If you are not receiving the newsletter, please SUBSCRIBE to read our views on IT Leadership issues, EA, Strategy, etc., and the latest news and events from EAdirections. Posted by George Paras in EAdirections at 19:33
Will EA Groups disappear in 2009?
Tuesday, March 17 2009
EA viability in the current economy is a hot topic these days. Just last week I was asked to respond to a statement recently read by one of our workshop attendees. It said that “Half of all EA projects will disappear this year because they can’t demonstrate business value”. My immediate reaction was that it wasn’t such a surprising statement. Historically, in any given year, many EA groups disappeared regardless of what was going on in the world economy, boom or bust. They faded because they were EA groups in name only, not doing EA work, or they were doing EA poorly. Sometimes it was because they tried to do too much EA too fast, or their internal champions left, their sponsors got a sudden case of “short-termism” (sometimes for good reason), their team members moved on, or any of a number of other reasons. A common thread was that they were not demonstrating value relevant to the needs at the time. How is this year any different? Not that much. In our short-term oriented culture, the climate for forward-thinking enterprise wide planning has always been rare. Nonetheless, organizations continue to work to improve their EA programs and many are introducing new ones for the first time or restarting past attempts. Why? Both IT and business leaders are telling us that they recognize that their past behaviors have been fragmented and have caused churn, lack of focus and wasteful spending. Many are burdened by inflexible, un-integrated solutions and excessively costly and complex portfolios. They are looking for a simplified and disciplined direction to guide them as they trim costs and position for the future, so they can do so in a strategically targeted fashion. So, don’t over-react to “half will fail” statements. The EA discipline is alive and well, or at least no worse than before. Should you ignore the signs and continue EA as in the past? Probably not. A solid EA leader always adjusts his/her approach with the times, biases and needs of their enterprise. Make sure you are focused, delivering value and addressing the needs of leadership. And don’t forget to be leaders yourselves – provide enterprise perspective and context so that decisions are consistent with both short term needs and longer term visions. If you make your EA program more transparent and actionable, while focusing on the right balance, you will be among the half that DON’T disappear! Posted by George Paras in Enterprise Architecture at 19:33 [ Comments ]
TOGAF 9.0 Released February 2, 2009
Tuesday, February 03 2009
The Open Group announced the release of the latest version of The Open Group Architecture Framework (TOGAF), 9.0, during the 21st Enterprise Architecture Practitioners Conference in San Diego this week. It is available for download at http://www.opengroup.org/architecture/togaf/.
During a briefing with The Open Group representatives last month, EAdirections learned about the improvements and additional components of TOGAF 9.0:
o The Architecture Content Framework, contributed by Capgemini, is a structured metamodel for architectural artifacts, intended to help an organization organize and relate the artifacts that they create. This is different than the reference models, TRM and III-RM, as they are targeted at organizing and related topical areas.
o The Architecture Capability Framework is intended to provide better guidance in the area of skills, organization, roles and responsibilities of architects, and a process for defining an appropriate architecture capability for your organization.
o Enhanced guidance on the usage of the Architecture Development Method, including the use of iterations, partitioning, applying TOGAF to different levels of architecture, and dealing with the specifics of different architecture styles, specifically security architecture and SOA.
o More, both explicit and implicit, improvements in the positioning of TOGAF as a toolset for ENTEPRISE architecture …. which, of course, we will be very interested in.
TOGAF has fundamentally not changed. The views, definitions, and perspectives that have characterized TOGAF for many years are the same. We have spoken to our impressions of TOGAF in support of Enterprise Architecture efforts many times, most notably in a webinar and corresponding survey in September, 2008. Our initial impressions of TOGAF 9’s changes are that they are all steps in the right direction, without having looked at the details yet. We will be conducting a more detailed review and making our findings know in the second quarter of 2009. If you have questions between now and then, don’t hesitate to contact Tim Westbrock at twestbrock@EAdirections.com.
Directions: EA practitioners should be aware of and investigate the features of TOGAF 9, with an eye towards the continued evolution of TOGAF as an EA toolset.
Posted by Tim Westbrock in Enterprise Architecture at 19:33 [ Comments ]
EA-Certified: To Be or Not To Be?
Tuesday, February 03 2009
We have been getting a lot of questions on the value of Enterprise Architecture (EA) certifications in the last 6 months. There seems to have been an increase in the offerings of EA certifications. Like many elements associated with EA, such as tools, frameworks, methods, continued maturation is evident. However, EAdirections generally cautions its clients about EA certifications because of the lack of accepted standards across the globe regarding the definition, scope, role and responsibilities of an Enterprise Architect. An organization needs to be clear on the intent and purpose of a particular provider’s EA certificate and associated process and testing for achieving their certification.
EA Certification providers generally include a mix of staff and guest/expert instructors. They all teach different things with different emphasis, have different qualifications required to receive certification, and, in short, do not provide anything approaching a standard, common certification across providers. Some have varying levels of dependency/sponsorship of tool and/or consulting vendors.
Commonly known providers include:
The Federated Enterprise Architecture Certification (FEAC) Institute offers training and an EA certification program.
The Enterprise Architecture Center of Excellence (EACOE) offers certification to its members, with four distinct grades based on workshop completion, years of experience as a practicing architect, reviewed performance on an EA development, and number of recommendations from peers. The EACOE is lead by Sam Holcman, also chairman of the Pinnacle Business Group and formerly President of the Zachman Institute for Framework Advancement (ZIFA), which no longer exists. )
IBM and Carnegie Mellon University offers certification to those who compete three courses in fundamental, applied and advanced concepts of EA. The curriculum was developed by CMU’s Institute for Software Research (ISR), including input from Dr. Scott A. Bernard, the author of “An Introduction to Enterprise Architecture.” The applied course includes hands-on modeling activities using IBM’s Telelogic System Architect tool.
The Open Group offers an IT Architect Certification Program (ITAC) with three levels of certification (Certified, Master and Distinguished) and is separate from, but complementary to, TOGAF certification. ITAC is publicized as being agnostic to method and focused on the skills and experience that should be evident at each level of IT Architect.)
The Global Enterprise Architect Organization (GEAO) has merged into the Association of Open Group Enterprise Architects (AOGEA) and we suspect that their certification program has been replaced with the Open Group offerings. This is supported by the fact that TOGAF or ITAC certification is a membership requirement for AOGEA.
We are interested in your experiences with EA Certification programs and the impact they have had on your EA Program. Directions: Understand the intent and origins of the EA certification options you are considering before you apply. While all of the certification programs have valuable educational components, they vary widely by content, concept and emphasis.
Outside the Box: Thoughts on Enterprise Innovation
Thursday, June 26 2008
Posted by Larry DeBoever in EA & Related Trends at 19:33 [ Comments ]
Inaugural IT Architect Regional Conference a Success!
Friday, September 28 2007
I spent a couple days 2 weeks ago presenting at and attending the IT Architect Regional Conference (ITARC) in Atlanta, sponsored by the International Association of Software Architects (IASA). The event, like the professional organization itself, is the brainchild of IASA founder and president, Paul Preiss. Paul is a former software architect who has taken on the cause of formalizing IT architect as a profession. Paul’s message is simple: “If IT Architect is to be a real profession, it must have an identifiable career path and the requisite accredited education and certification components.” To put his passion, scope and outlook in perspective, Paul put the following question out to the audience in his opening speech, “What is an IT architect’s responsibility to the world?” He spoke of the roles that emergency workers, construction workers, and other professionals played in the aftermath of Katrina and other disasters. Certainly there is also the need for software architects and infrastructure architects to help get things back up and running as soon as possible, as well as supporting rescue and recovery efforts. This analogy is very typical of the grand vision that Paul and others at IASA have for IT architects. It is a long way off, but IASA is taking steps to begin advancing the profession. EAdirections supports their efforts and will be taking an active role in helping to define and accredit (as well as deliver) the curriculum for IT architecture. 2008 will see the beginning of a formal, accredited curriculum for IT architects.
Question for our readers (feel free to respond in the comment section): If a profession requires a defined career path as well as formal education and certification, do you see Enterprise Architect as a node on the career path of IT Architect, a profession of its own, and/or just a role to be played in the strategic planning function of an organization?
I also enjoyed the perspective of Ralph Whittle on enterprise business architecture. Ralph co-wrote a book on Enterprise Business Architecture with Conrad Myrick that outlines much of what he had to say. I hadn’t read the book yet (I will now), so I was glad that I caught his session. His approach is similar, but more detailed and supported with specific company experiences, to the approach that we defined at the META Group utilizing Enterprise Value Network (EVN) analysis. Ralph bases his approach on defining the value streams of the enterprise, and then evaluating each stream (such as Order-to-Cash) along 4 dimensions: vertical, horizontal, extended value chain (supplier-to-customer), and time to market. This is really the valuable part of his approach – looking at it from these different dimensions.
EAdirections looks forward to participating in future ITARC events and working with IASA to advance the profession of IT architect. Posted by Tim Westbrock in Enterprise Architecture at 19:33 [ Comments ]
Measure Capability by Effectiveness, not Maturity
Friday, July 06 2007
For years we have seen and heard organizations, consultants, analysts (yes, even me) and other EA practitioners discuss the notion of EA MATURITY. Most of these discussions focus on metrics and levels similar to the Capability Maturity Model (CMM) process improvement system developed by the Systems Engineering Institute at Carnegie Mellon University. As a matter of fact, in the late 1990's, I was part of a group at The META Group that developed and published a set of criteria to assess EA maturity similar to CMM. Over the years at META and since, though, I have started to develop a different opinion of using CMM-type assessments for enterprise architecture processes for a few reasons: 1. CMM was originally developed for project-level systems engineering capabilities. While some of the concepts are applicable to an enterprise-level planning process, the measures of success are not. Systems engineering has more tangible and immediate outcomes by which we can see if improved process maturity is resulting in more successful outcomes. The same is generally not true of EA.
2. In conducting several CMM-type EA process assessments, one of the experiences I had was that the exercise of collecting the responses to questionnaires aimed at rating EA capability maturity on a scale of 1 to 5 rarely resulted in any kind of consensus on levels of maturity. That exercise usually led to some very valuable discussions and outcomes, but the rating itself was far too subjective and inaccurate.
3. The measure of maturity itself tends to rise with age; however, the outcomes may or may not be improving as maturity increases.
I have concluded that it is better to accept the subjective nature of EA and instead assess the capabilities of an EA program based on several critical factors that indicate how effective the program is within the specific organization. The categories are similar to the ones that you have traditionally seen in EA maturity, but instead of rating the factors on a scale of 1-5 representing initial, repeatable, defined, managed and optimized; I use a scale that goes from significantly inhibits effectiveness to significantly enables effectiveness. I have outlined several of these factors in an article in our research area entitled Critical Success Factors for EA Effectiveness. While this type of an assessment is a step forward in helping an EA team better understand its opportunities for improvement, obstacles to overcome and leverageable strengths; the best measure of success is still going to be the impact on shareholder value. However, I believe that being effective is a surer path to increasing shareholder value than being mature. Posted by Tim Westbrock in EA Maturity / Effectiveness at 19:33 [ Comments ]
EA Futures From 22F
Thursday, June 14 2007
At this very moment I am stuffed in 22F on a completely full flight returning from New York and it gave me a chance to look at my journal, and review the notes from a couple dozen or so conversations I have had this week and last. While none of my conversations were specific to EA, there were a number of very consistent and complementary themes which will, I suspect, impact the EA of complex organizations over the next several years.
First, the conversations.
Yesterday, I spent several hours with Hardev Dhindsa who has a small firm, Exact Solutions, whose iWatch technology is installed on roughly 2,500 performance critical servers in 7 of the 10 largest investment banks (e.g. Lehman, Goldman, JPMorgan, Barclays) and no where else – let me repeat – “no where else”.
I was introduced to Hardev by a mutual friend who thought I could give him some insight into the potential market for his product and help with strategic planning. As that conversation progressed, Hardev and I began talking more and more about the evolution of IT (in the broadest sense) over the next few years.
(At some point I will write more about the evolution of ‘systems management architectures’ but for the moment let me say that Hardev has built a query-level performance monitoring tool that is lightweight, non-invasive and used by all of these banks to ensure very high (subsecond) service levels for SQL queries. The simple fact is that tools from CA, Tivoli, HP, BMC, et. al. provide effective OS monitoring, database monitoring and network monitoring but they don’t provide insight into the performance of SQL queries. Nor do these tools help ‘support staff’ identify which queries create problems. Hardev’s approach is as brilliant as it is simple. And DBAs faced with unrealistic pressures to ensure performance should embrace iWatch to simply prove – “Hey, it’s not a database problem!” But that’s another blog.)
On Monday, I spent a couple of hours with Harold Heath who is Enterprise Technical Architect at Citigroup and someone I have chatted with for awhile. In the course of that conversation, Larry Burgess, another EA at Citi who I have met before, joined us.
Last week, I was at the GoldenGate User Group Conference where I delivered the closing keynote. (In the interest of full disclosure, I have been on GoldenGate’s Board for about four years and I think they are the leader in transactional data management.) I had the chance to speak to a number of GoldenGate’s clients and partners. Attendees included end users such as UBS, JPMorganChase, Visa, BofA, First Data, Shell, Sabre, MGM, ADP, etc. and partners including IBM, HP, Teradata, Ingres, GE Healthcare, Cerner, Amdocs, etc. The conference had one of the best CIO panel discussions I have ever heard. On the panel were Roger Burkhardt who was CTO at NYSE for 6 years (before recently joining Ingres as President & COO), Penny O’Hara who is CIO for BT Health which is leading the re-engineering of healthcare delivery across the UK, and Craig Murphy who just retired as CTO of Sabre Holdings.
Now to my journal.
So, I talked with and listened to a bunch of really bright people. At first my notes appeared to be all over the road but I eventually reduced them to a consistent set of nine, very concise, ‘EA Futures’. After reviewing my first draft I decided that my desire for conciseness might, unfortunately, demonstrate the Law of Unintended Ambiguity (I just made this Law up), so I thought a little ‘translation’ might clarify as needed.
Here we go…the 9 EA Futures to come out of my recent conversations are:
1. ‘Electron-ification’ of all business processes is the goal. Translated as “straight-through processing in as ‘real-time’ as we can make it is how we want everything to work.”
2. Self service everything. Translated as “most users that need to interface with #1 should just do it themselves any time they want; they get better service and we reduce headcount, wahoo!!”
3. Active data warehouses. Translated as “‘electron-ification’ requires ‘self-service’ which means information has to be current not just accessible”; said differently, “we can’t do #1 and #2, unless we do #3”.
4. Pan-process/pan-service. Translated as “we need to take an enterprise view of everything (i.e. #1, #2 and #3”) whether we are talking about business processes or application services”.
5. ‘XML-ification’ of the enterprise. Translated as “this is how #1 thru #4 talk to anything most of time, and talk in a very agile way, but XML has a lot of overhead”.
6. Horizontal scaling is a must. Translate as “#1 thru #5 means way more bandwidth, way more storage and way more processing so you better think in terms of building out and not up”.
7. Cost-effective computing is required. Translated as “relentless focus on driving down the cost of terabytes, gigabits and MIPS in the context of #1 thru #6 and the requirement that you bow toward San Francisco everyday” (note: San Francisco was Gordon Moore’s birthplace).
8. Open systems is a key strategy. Translated as “Linux” or “you can’t get #7 done without it, and if you can’t get #7 done forget about #6, and if you can’t get #6 done you can’t afford what’s really required for #1 thru #5.”
9. Zero downtime. Translated as “planned outages are just as bad as unplanned outages so you better correctly architect and enable #6 thru #8 so you can deliver #1 thru #5”.
Yeah, it was a stimulating two weeks. And this blog barely scratches the surface. Posted by Tim Westbrock in EA & Related Trends at 19:33 [ Comments ]
Does EA Figure into Strategic Sourcing and Procurement?
Tuesday, June 12 2007
Over the last year or so, I have been working with a company, BluePrint Marketing, which specializes in improving the sales and marketing capabilities of IT vendors. During that time, two things have become clear to me. 1) While IT vendors are increasingly aware that EA plays a role in strategic sourcing and procurement decisions, they aren’t sure how to leverage (or even identify sometimes) the EA team. And 2) the EA teams of most companies are not getting involved in strategic sourcing and procurement processes early enough to influence the strategic direction ... more like an afterthought. Let's tackle the vendor issue first. Vendors need to understand that EA is a process that is focused on aligning current activities (projects, operations and investment decisions) with the strategic directions of the business. Leveraging the EA team and its plans, models, and processes would enable them to have conversations earlier in the sales cycle and more closely align their offerings with the capabilities that the business requires for significant change. Most vendors want to be more than just a commodity provider, but they lack the access to strategic thinkers in their target accounts. The EA team can not only provide the access, but also the interpretation and linkage back to business strategy. Given the relative lack of maturity of EA in many companies, the challenge for vendors is figuring out if the EA team is mature and credible enough to influence the sourcing and procurement decisions. On the client side, increasingly we are seeing that EA teams are getting better at publishing standards and design guidelines that influence commodity procurement and design activities at the project level. Inroads are also being made in many companies and government entities to influence capital planning and portfolio decisions. One of the missing pieces seems to be sourcing decisions. We believe the key to linking EA with sourcing decisions is in the development of service management strategy. More on that later… Vendors who want to leverage client or prospect EA teams involvement in sourcing and procurement decisions are going to have to identify the EA team and its role within the target company earlier in the sales cycle. End-user EA teams who want to affect sourcing decisions more directly are going to have to develop service management strategies that identify ahead of time services that are candidates to be outsourced and those whose criticality to business value demands that they be an internal core competency. Posted by Tim Westbrock in EA Maturity / Effectiveness at 19:33 [ Comments ]
Dangers of 'EA Senility'
Friday, June 01 2007
In the last couple of weeks, I have spoken to two clients who had common symptoms which I have termed 'EA Senility'. Both are Chief Architects in large, global companies. Their EA functions are mature by any measure. Strong EA governance and communication. Completed TOGAF-like frameworks that are comprehensive, fully populated, current and well crafted. Artifacts are polished. In short, they are models of EA excellence and could serve as case studies for newly minted EA teams. There is only one problem. Both Chief Architects believe they are slowly losing the support of leadership - both within IT and the BUs. By 'loss of support' I don't mean 'anti-EA' sentiment but rather a loss of relevance and interest. Both wanted insight and advice on how they could return to their 'glory days'. One of the clients had just had a meeting with their new CIO ,who was hired from the outside after the long-serving CIO retired. One of the first things the new CIO asked was "How is 'open systems' incorporated into the enterprise architecture?". The fact is there isn't any open systems 'stuff' in either client's EA. No Linux. No MySQL. No Apache. 'No nothin'. I found this hard to believe. In talking with them I found that projects had come forward with open systems proposals but, it became clear to me, that 'governance' and 'process' and 'standards' eventually ground out innovation. The EA teams had effectively become inhibiters of business change. In their old age they had gotten away from the raison d'etre - to enable the business. When, as architects, we stop looking forward and we stop innovating then we should retire. We have become 'the man'. We have become senile. 'Senility' doesn't happen to the young, it happens to the 'mature'. Posted by ldeboever in EA Maturity / Effectiveness at 19:33 [ Comments ]
Enterprise Transformation
Sunday, April 01 2007
Looking beyond the clutter of day-to-day priorities, transformation is an ever-present and fundamental driving force for the enterprise. High performing C-Level business executives commonly have a business vision for an enterprise that is bigger, better or different than it is today. This vision yields a set of transformation goals such as simplification, cost reduction, increased agility, better service to customers, and improved quality, efficiency or effectiveness. The scope can be large or small. The approach can be evolutionary or revolutionary. The pace can be aggressive or reserved. In all cases, the “transformed enterprise” is the systematic realization of the vision. By embracing transformation as a core concept, IT executives use it to steadily guide their organization to the transformation target. EAdirections
Thursday, March 22 2007
With over 50 years of leadership in Enterprise Architecture, including the launch of the EAS service at the META Group and the Enterprise Architecture Conference (EAC) with Shared Insights. We defined many of the current best practices in EA, influencing TOGAF, NASCIO and others along the way. Posted by gparas in Advice at 19:33
|
|
 |
|
 |