Posts Tagged ‘it governance’

Agile in a Waterfall Enterprise – Agile and PMP

January 29, 2010 2 comments

If you’ve been working in software development and system implementation for large enterprises like I have, you can probably relate to the tension between knowing that Agile approaches really do have good results, but the governance processes of the enterprise are Waterfall.

I’ve recently been working with a team who have been trying to adopt Agile methods, but who rely funding from our central Project Approval Committee (PAC).  The PAC submissions and governance processes such as Information Security Certification and Architecture Certification are designed around Waterfall, not Agile.  So, we have something of an impedence mismatch.

Read more…


Culture of Communication vs a Culture of Fear

October 20, 2009 Leave a comment

Does your organisation have a culture of communication or a culture of fear?

This thought came to mind while I was having a discussion with a System Owner recently.  He wanted to establish a forum in which like minded people could share their experience on how they had solved various technology problems they faced.  Examples of these include how they achieved SOX compliance or high availability.

At first blush, this seems like a great idea.  Surely there are people in the organisation who are facing problems that have already been solved.  This forum will be a good chance to encourage reuse and help people develop their presentation skills.

What about the culture of fear?

There is a dark side to this well intended idea that came to mind.  What if someone presents their solution and we find that their solution is contrary to one of the myriad standards or strategies in the organisation?

In a culture of fear organisation, I imagine there will be someone in the room who shouts out that the solution is not strategic or non compliant.  Now that it’s in the open, the sharing team will be lined up and shot and the organiser of the forum reprimanded for instigating proliferation of non-compliance.

Perhaps that’s a bit of an exaggeration.

Eliminate the Culture of Fear

If you want more reuse and communication in your organisation, you need to eliminate the culture of fear.  People need to feel free to tell the truth about what they are doing without fear of reprisal.

Standards and strategies are valuable and important.  But we should be careful about the organisational impact of fear.  What happens when people stop speaking freely?

{Market}ecture vs Central Planning

August 29, 2009 Leave a comment

The term marketecture I got from a clever fellow at Queensland Treasury Corp who responded to one of my posts about applying free market principles to enterprise architecture.

A short time back I wrote about the merits of applying free market principles to Enterprise Architecture rather than the central planning model we generally see.  The premise of the post was, if central planning didn’t work for broader economies, why do we think it’s going to work for our large enterprises?

While I was working at Citigroup in the Global Architecture Team, one of our objectives was to identify duplicate capabilities and eliminate them.  While performing this task, there was a tendency to frown upon the development teams who had built this duplicate capability.  On the surface, this makes sense.  But as you dig a little deeper, you’d often find the duplicate capability had done the incumbant one better (at least).

My worry about punishing the duplication is that we were actually stifling innovation.  Innovation often comes when an ambitious person or team is determined to make things better.  There is almost always an existing capability that will be duplicated.

In the central planned process, only sanctioned or approved innovation can take place.  Those same ambitious innovators above are expected to present their case or idea to some planning committee who will prevent the innovation until they are satisfied it is totally risk free and will result in ROI for the company.

The primary problem with this is, those ambitious innovative types generally detest process and bureaucracy.  Next problem is, we cannot be certain that something innovative will succeed – until it’s been done at least once.

How can we have Marketecture

If we agree that innovation requires the freedom and suffers in a central planning environment, how do we do marketecture in an enterprise?

I think that’s grist for the next post.  If you have any thoughts or comments on this, please post a comment.

Granting a Monopoly to your IT Suppliers

August 28, 2009 Leave a comment

In Enterprise Architecture we are often fixated on standardization of technologies across our enterprise.  We publish standard technologies for services such as DBMS, Storage, Network as well as application services like workflow, reporting and reconciliation.

The rationale for standardization is pretty straight forward.  Diversity is costly.  Each technology product carries with is operational risks that must be managed.  There are legal and commercial relationships to be managed and operational and support costs for the platforms.

The down side of standardization

In this zeal for standardization though we might be blind to a few downsides of standardization.  Here are a couple:

  • Granting a Monopoly – through standardizing on a single vendor removes the competitive pressure on the vendor.
  • Concentration Risk – this is a term from financial markets that means too much of your risk exposure is concentrated in a single security or customer.  What happens when your standard supplier goes bust, which seems to be happening more frequently these days.

Bad things happen when you grant a monopoly

In your company it is no different than the broader economoy, when you grant a monopoly in a given sector, you eliminate the competitive pressure for a supplier to deliver quality and innovation.  You also put all your eggs in one basket.

What’s your view

Is this just too hypothetical? I’d like to hear other’s view on the topic.  So, please comment or direct me to your blog.

Target State Architecture without a Project

July 28, 2009 1 comment

Today I found myself explaining why the Department or Domain I have been responsible for nearly 6 months has not Target State Architecture.  Hmm.. you say.

Seriously – As an IT Architect responsible for a particular business domain in my company, one of the things I should create and maintain is the Target State Architecture.  If you’re an enterprise architect, this is quite obvious.  The problem I faced in developing target state though was the notion that in a Global Financial Crisis when a department head has decided they are not going to spend any money in the fore near future, the target state looks pretty much like the current.  It’s not the Dream State we’re talking about.  So, getting motivate to draw a diagram or write a description about something that isn’t likely to be is not fun. Read more…

Mandated vs Compelling Shared Services

July 10, 2009 Leave a comment

If you’ve worked in a large enterprise you’ve surely come across the situation where there are more than one implementation of what seems to be the same thing. This sort of duplication really upsets our sensibilities. Our first reaction is to say how wasteful that is and wonder how to get everyone to reuse the same service.

I was reminded of this issue in a recent conversation with a Big n consulting firm. The fellow I was speaking with referred to the strong governance process in my organization as the reason why we should see this sort of redundancy eliminated. To this I replied with a my rant about how strong governance a euphemism for mandating that solution architects use the standard or enterprise technologies in their designs was not the right way to achieve the best outcome for the business. I point out that central planning has proven in a grand to be a failure. Why if this is so for an economy is it not so large enterprises?  Read more…