Thursday, June 30, 2011

Six Reasons Why EA Should NOT be Assigned to the IT Department

I have always disliked working with the "big architecture" people. It was only in the last 5 years that I came to realize why.  Enterprise Architects are often software developers who have reached the pinacle of programming greatness. They can solve massive problems and are truly amazing software developers. However, they often lack business accumen. As such, their solutions don't consider the most important part of the solution - the business' goals:


EA is short for Enterprise Architecture:

  1. EA ≠ IT Architecture
  2. True EA leads to redistribution of authority, which is beyond CIO jurisdiction.
  3. EA value proposition (i.e. standardization vs. innovation) is solely business realizable.
  4. The primary goal of EA is to build coherent enterprises, not better IT systems.
  5. Synthesis takes precedence over analysis.
  6. EA failure is an organization failure, not an IT failure.
I came across this post on LinkedIn and felt I needed to share. It was posted by a person named Pallab S who is an Evangelist [Enterprise Architecture Practice] at National University of Singapore | Institute of Systems Science.

Saturday, June 25, 2011

Agile In Regulated Software - Partnering


This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:
Photo By: JD Hancock
Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it be likely that you will produce a better product now. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with the business and marketing? Here are the difficulties you will likely face:
  • Goals are different
  • The phases and corporate dialect are different
  • Time frames of when decisions are made is different
  • Required documentation will be different and address different goals
  • Stakeholders will feel comfortable giving verbal requirements, but you must to document them, get them formally approved and finally build them into working software
How do you partner with the business and still meet your commitments? Follow the practices I presented earlier and stick to the following principals:
  • Consistent focus on activities that add business value
  • Build trusted partnerships
  • Constant customer engagement
  • Continual process and practice improvement
  • Be collaborative and transparent
  • Work together: No heroes, lone wolves, or cowboys
  • Pay attention to the team and adapt as needed