Posted by Jack Santos

The term “organic” is making the lexicon rounds, and has come a long way from its health food store beginnings in the 70s.  Take organic business growth (versus growth by acquisition).

The most recent manifestation of “organic” came from a column in Forbes, by Dan Woods.

Dan’s approach, and back-handed chastisement of traditional IT, certainly fits trends that we at Burton group talk about.

Specifically the  consumerization and democratization of IT.   A recent Computerworld report brought the point home:  Internet access is now a human right, according to the EU.

So, as information technology continues to become integrated in everyday life,  the trend toward “organic IT” will only get worse – or better depending on your POV.

That’s why I often talk about IT integration versus IT alignment.

But the flip side of organic is chaos (both data and process) and unintended consequences.  Think invasive species. 

The business has ultimate control and responsibility for both data and process, and the organic approach, if not managed, can negatively impact both.

Usually what that means is that the organization looks for someone to mediate the decision-making and organizational/systems decisions…and the only piece of the organization that has the expertise and (ostensibly) the umpire-like lack of line responsibility skin-in-the-game is IT – so IT ends up managing the use of technology, and all that goes along with it -- including governance processes.

Whether governance fully involves the business, or IT just takes on the mantle of responsibility is a tricky balance.  The latter often occurs at the urging/delegation/abdication by business units.  I would submit that IT needs another set of skills – that of making sure that technology (read data and process) decision-making is business driven.  

It’s a  biblical “give a fish vs. teach to fish” scenario – but  teaching to fish assumes learning acceptance by the target, and some level of skill by the teacher.  And these skills are not technical skills – but relationship and influence skills.  Not the usual courses taken by a rising C programmer, or a database administrator.

When getting the business to be fully involved in technology decision-making doesn’t work well,  it's just a short hop to blaming IT, or for IT to overreact (again as proxy to the business) and set inflexible standards that squelch business innovation.

That’s why architecture (and governance) is so important.

It’s all about collaboration and communication, and neither a soviet-style centralized approach (which, incidentally, has strong similarities to how capitalist companies are managed), nor a total laissez-faire anarchy (which is where organic has strong tendencies) will work.

Which reminds me of a t-shirt…

“Give a man a fish and you’ll feed him for a day, teach a man to fish and he’ll sit in the boat drinking beer all day…”

Would that be…organic beer?

Posted by Mike Rollings

Last week I attended the first meeting of Penn State's IST EA Advisory Group.  This group is helping Penn State define undergraduate education, graduate education, and professional development education and research related to enterprise architecture.  The four different teams really took off over the course of the 1.5 days we were together.  Many good ideas came out of the kickoff and I look forward to helping these ideas move forward as part of the professional development team and the group.

However, even among those at this event (around 70 people) who have been around EA for a long time, the question still remains -- What is EA? Thankfully the leader of the session did not go down this rathole.  Instead we focused on what needs to be done to develop enterprise architecture professionals. 

Who is an EA professional?  The point of view I shared with the professional development team was that I did not think that our focus should be just for those that identify with EA.  If you have to decipher the term EA before you can get value from the courses then I believe we miss a great opportunity to introduce useful methods and disciplines to many business and technology professionals.

For those of you who have followed my writing in Burton Group research and also this blog, my position should not be surprising.  For instance, since we launched our enterprise architecture coverage 18 months ago I have been calling for a focus on business outcomes, influencing decisions across business and IT, and a move away from the notion of an ‘EA devotee society’.  This is just a part of the brokenness of EA.  I would much rather discuss how to correct EA-related fractures in organizations and describe competencies or practices (e.g. business optimization techniques, dependency analysis) that heal the patient, rather than first convincing someone that they need EA. 

I think that the competencies that make up EA should be offered to a broader audience of professionals.  For instance, the business strategist who is looking for a way to broaden their ability to examine implications of a strategy to include a technology impact assessment.  I don't want to put a barrier between them and the method by first having them get the term EA. 

I believe that the broadest benefit comes to those who focus on the competencies and not the EA term.  The reason we care at all about the analysis techniques etc. in the EA bucket is because we want to improve business outcomes – not because we care what you call the bucket!  When you focus solely on the bucket it leads to ivory towers, ineffective processes, a lack of participation, and low stakeholder commitment. I would rather focus on the value to the business.