Below is a repackaged copy of my “Enterprise Architecture in Academic Environments” presentation that I gave at EDUCAUSE Mid-West Regional Conference 2008. It is packaged as a Quicktime Movie.
Several speakers this afternoon.
Seven Traits of Effective Enterprise Architecture (EA)
Speaker number 1: Mark Denne, Partner, Accenture
Business Alignment – Must define its value in terms of the business measured in the business’ currency. You must show that there are savings when you do EA.
The panel is reitteratng that you cannot buy SOA in a box. It is an architecture, a long term process and transformation of the enterprise. It is beyond the scope and capability of the I.T. folks but really has to come from business leaders – the C-Level executives.
What impact with the economic downturn have on these SOA projects? Those companies that are thinking tactically and quarter-to-quarter will be at greatest risk of failure. Those that are more strategic thinking will see the value and move through the downturn.
Standards – missing standards. The vendors need to fix it. The standards actually come out of the marketing arm not the R&D of the vendor’s shop. There are 156 standards that I’m tracking.
REST: Tom on RESTful services. Chose the RESTful services because the WS standards weren’t really ready.
Enterprise Mash-Ups: Doing real applications of value in rapid iterations is a way to demonstrate the value of SOA. Mash-ups as an orchestration and integration layer. Google maps as a service provider for mapping and real-time traffic information. Mash that with delivery systems inside the enterprise and delivered to a web browser inside the truck. Can save a company $15-20K a month by missing traffic issues.
Business Process Modeling:
“There is a marriage that everyone keeps talking about but they have yet to go on their first date.” The business process people think that they should own the BPM/BPEL layer. The I.T. folks think that they know what it takes to actually implement the process so they are uncomfortable with giving complete control to the business people. There are the BMP Tribe, The SOA Tribe and the EA Tribe and they aren’t talking even though they are completely intertwined.
David Linthicum wrote, “Enterprise Application Integration”
Dysfunctional architectures that are currently deployed have led to enterprise that are locked up and unable to really improve because of the complexity. The activities ahave all be driven by tactical needs not strategic needs.
Enterprise Architecture are raising their hands and saying we need a “master city plan” but they don’t get the budgets or support so they end up acting tactically also.
Need to convince people that the SOA technology and strategic planning are important. Need to start with the business case. The business drivers: Reduction of integration expense, increase in reuse, greater visibility, business empowerment and increase in business agility.
“Think big, start small, succeed often”.
Need to find a champion, a LOB manager, CIO, management-level architect or other architect.
Need to build the business case and show ROI though the calculation can be difficult because there is no historical data (SOA implementations), it is difficult to differentiate between a well-architected SOA vs. non-SOA architecture and what do you gain from agility.
We are trying to decompose the enterprise into functional primitive behaviors that we can then re-orchistrate as we need to. We don’t do code level re-use, that has never work. We deal with behaviors that are put behind a neutral dial-tone that lots of different technologies can take advantage of.
Business Intelligence: Visibility into data, business processes and into levels of compliance. Once we have these services that are communicating outside of their technology stack, then we can peer into the interactions and information. We can then deliver that information in any number of ways: a spreadsheet, a dashboard on a blackberry. This is “sex-in-the-screen kind of stuff” the C-levels love.
Agility: Need to identify the need for agility for the business itself.
When not to apply SOA: when business requirements are stable, when the IT environment is homogeneous, when current tools provide sufficient visibility, when performance requirements call for efficiency over flexibility. Don’t be led by VDA – Vendor Driven Architecture.
JBOWS – Just a Bunch Of Web Services – nothing is solved when all you do is build a bunch of web services. Service enabling is not where you gain from SOA. It is the consumption and re-use where the gains come. You must design for re-use.
Start with the business requirements and architectural planning, then back the technology into the problem domain. You cannot buy SOA, it is something you do not something you buy. If you buy and ESB and a bolt it onto the enterprise, you will just make things worse. Note that governance and security are systemic as is performance engineering.
Architecture should be: implementation-independent so that is it stable as technology changes, business process-indpendent so it stays stable as business changes.
From the Open Group’s Enterprise Architecture Practitioners Conference in San Francisco.
I had breakfast with David Jackson from Boston university. David is working on building a consortium of business schools who will offer something like an Executive Master’s of Enterprise Architecture degree. This would be similar to Executive MBA programs in that students would be coming in with real life experience.
Two parts of this are interesting to me.
The first is the tools and techniques that end up codified as part of the curriculum. What they teach will lead the students towards being certified (via the Open Group’s EA Certification program) Enterprise Architect. That certification requires at least two years of real-life experience. The certification also includes demonstrated proficiencies in a variety of tools and techniques.
When people start entering the market who are certified with these skills and knowledge of these tools, that will drive the adoption of the standards. Hopefully, rigorous yet simple tools will grow out of this market.
The second will be the “blow-back” force to the ERP vendors. These ERP vendors will need to demonstrate how their products fit in multiple architectures rather than provide a complete architecture in and of themselves. At least that’s what I hope.