Category Archives: IT Architecture

Measuring the value of projects

Jason Uppal of Quickresponse gave a talk on Building Enterprise Architects at the Open Group’s Enterprise Architecture Practitioners Summit. He mentioned that Toyota judges project success based on

three corporate objectives:

Profit from the Program
Market Share

These facets got me thinking about our post project reviews. We tend to measure our projects on whether or not they were done on-time and under-budget. We have post-project reviews that ask, “how could we run projects better in the future” but they are focused on the project process. We don’t really evaluate the project on a set of facets. So we evaluate “What” and “How” but not “Why”.

As I think about this, I think the interesting facets for us would be:

  • Did this reduce costs over the long run – e.g. have a reasonable ROI
  • Did this “improve” the enterprise architecture – did it reduce redundancy, reduce complexity, advance strategic initiatives
  • What did we learn about the enterprise in the process?

Technorati Tags: , , , , ,

Old meets new – You can follow the New York Times on Twitter

I just discovered that there are several twitter feeds for the New York Times. These feeds include a main New York Times feed at

along with several specific feeds:

You can find most of them by going to the main URL and look at the “following” list on the lower right hand corner. You can then follow the NYT stories as they are published in each section in twitter. Pretty cool.

This continues with the general trend of “the content I want, where I want it, how I want it, when I want it”. The great mash-up continues.

Technorati Tags: , , , ,

EA Practitioners – EA Best Practice Management

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.

Continue reading

EA Practitioners – SOA Reality Check Panel

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.

Technorati Tags: , , , , , ,

Keynote from EA Practitioners: SOA and EA – in the real world

David Linthicum of Zapthink is speaking.
Conference materials live at

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”.

Building support:

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.

Technorati Tags: , , , , , ,

Enterprise Architecture as an Academic Study

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.

Technorati Tags: , , ,

SOA – Bumps in the Roadmap

In preparing for battle I have always found that plans are useless, but planning is indispensable.
Dwight D. Eisenhower

Some time ago, I was on the circuit talking about Service Oriented Architecture and a roadmap for moving forward. Since then, we have had many false starts and hit many snags along the path. There is slow movement: we are standing up an ESB for testing, we have started a project to expose Course Roster data as an enterprise service, and groups are moving towards Web Services as there preferred integration technology. This is still a long way away from from SOA as an enterprise architecture.

Continue reading

EDUCAUSE ITANA Constituent Group Meeting

ITANA’s Constituent Group meeting was on Thursday at 4:55PM. Approximately 40 people attended the meeting. Many of the attendees were from newly formed architecture groups.

The notes from the meeting are posted on the web site: EDUCAUSE 2007 CG Meeting Notes


My slides are posted on the EDUCAUSE Annual Meeting Site: IT Architects Session

Future State Models

The Gartner Group describes Enterprise Architecture as:

“The EA group will translate business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise’s future state and enable its evolution.”

The statement that caught my eye was “models that describe the enterprise’s future state”. Keith and I talked about future state models. We both agree that it is impossible and not very productive to produce and all-encompassing future state document – a single document that describes the future state of the whole enterprise. It is impossible because of the complexity of our enterprise and the fluidity of the various disconnected portions.

We do future state documents for small project spaces. For example, there is a future state document for our Course Roster Interface project. This future state describes an Web Service and Event Driven architecture for all services that need Course Roster like information.

I am currently working on one with Human Resources for their employee forms delivery systems. Having the future state model gives them a star to guide by. It also provides them with talking points as they work with other campuses and stakeholders.

This started me thinking about what is the right level for a future state document? Is it just project by project? Should it be at a higher level like a domain within the enterprise (e.g. Student Enrollment Information, HR Employee Information)? Are others doing future state models?

Beautiful Data Visualizations

These movies of air traffic flight patterns are making the rounds on the internet. They are really gorgeous and intriguing to watch. One of the cool things about movies like this or Hans Rosling’s work is the fact that they transform pretty boring data into beautiful moving pictures. These pictures let the larger patterns emerge. These movies make the data easily understandable by almost anyone.

Rather like what I try to do at work in some ways. Make pretty pictures that display complex systems in simple terms.

Very cool stuff.


Technorati Tags: ,