NICTA survey on SOA projects

NICTA are conducting a survey on SOA projects.

“We are conducting a survey of SOA implementation projects to determine cost and effort factors associated with such implementations. We would be grateful if would complete the survey or pass it to the appropriate person within your organisation. We are seeking as much input from different sources as possible so if there are others in your organisation or beyond who you feel could complete the survey we would be grateful if you could forward this email to them.
The survey can be found at:
http://zlix056.srvr.cse.unsw.edu.au/Questionnaire/qs/create
It should take no more than about 15 minutes to complete the survey.
Your answers are completely confidential, and can also be anonymous. If you would like a copy of the results of the survey please include you email.

Once the survey closes I’ll post my responses and comments on the results (assuming they’ll be publicly available).

STP 2.0 – smart touch processing

A common goal of many process-oriented organisations is to increase throughput through straight-through processing (we’ll call it STP 1.0).  This can be tricky in environments where automating a bad decision can have quite substantial impacts.

In addition to applying smarts to increase our throughput,  we should go the next step and apply the smarts to know when a manual decision by a knowledge worker is required.

James Taylor alludes to all this in his recent blog posts on the Gartner BPM conference.

This idea needs a name – Introducing STP 2.0 – Smart Touch Processing.

BOTW: Top 10 tips for presenting enterprise architecture information

It’s been over a week since the last one, but here is #2.

Top 10 tips for presenting architecture information:

  1. Know Your Audience
  2. Carefully Choose Your Approach
  3. Set the Context
  4. Increase the Information Resolution
  5. Show Data on a Universal Grid
  6. Use Small Multiples
  7. Recognize that Content is King
  8. Leverage Industry Standard Notation Techniques
  9. Incorporate Relevant Facts and Figures
  10. Follow the Particular, General, Particular Pattern

Read more here.

BOTW: Ten Pitfalls in Establishing an Enterprise Architecture

Ok, time to introduce bookmark of the week (BOTW).

Gartner on ‘Ten Pitfalls in Establishing an Enterprise Architecture’.

A good article in itself, that links you to the Gartner site.  There we find a couple of interesting video snippets:

Phil Allega on the role of an enterprise architect: (note, these are across both buisness  & technology)

  • identify business obstacles
  • discover opportunities for efficiency & consolidation
  • mirror to the strategy – help the business understand how the execution of their grand strategy is playing out (I guess this helps with fine-tuning)
  • future impact specialist – what are the short, medium and long-term business and technology impacts of decisions we make today?
  • steward of all interrelationships in the EA, be they between business processes, the technology that support them and so on.  Basically, stewards of the ‘EA’ (the core business processes and technology that support the execution of the business’ operating model – Ross et al)

Brian Burke on CFOs and Enterprise Architects – EA can contribute to key areas of interest for CFO:

  • capitalising on market changes to driving business growth – identify coming trends & ensure the business is ready [ie has the right foundation for execution] to either lead or be a fast follower
  • reducing costs – EA has visibility of business assets & how they can be rationalised, and buisness project portfolio & which can be culled because they are no longer aligned with strategy
  • measuring business performance – providing models that facilitates this – such as (ta-daaa) the “Gartner Business Value Model”.  TODO: find out what this is.

Harvesting information for your service registry

I was just going through some old notes from last year’s Australian Architecture Forum. One of the presenters spoke about how service registries are very useful, but often will end up out of date with the real running systems due to the maintenance overhead.  The suggestion was to harvest information from various sources, such as:

  1. version control
  2. continuous integration servers
  3. interface documentation
  4. task / issue tracking systems
  5. application servers and message broker

I’ll be looking for ways to add these to the governance toolkit, as  regardless how many rules we put in place, people will always find ways around them, often for what sounds like good reason (so they don’t tell you!)

Reference architectures

Zapthink remind us of the value of reference architectures.

The Ujuzi take (with apologies):

  1. build on a pre-existing reference architecture where possible (this is the standing on the shoulders of giants bit)
  2. if  you are committed to a vendor’s product, decide how deeply you are prepared to entrench it in your architecture and then build on their best practices for the chosen bits
  3. maintain a register of lessons learned (and solutions) as you go through projects
  4. document antipatterns and how to avoid them
  5. document new patterns and how to apply them
  6. document what doesn’t work as advertised – whether it is a vendor product capability or just an architectural approach
  7. PoC, PoC, PoC

Practical Perspectives on Architecture, Process Improvement, Software development and more