Wednesday, April 12, 2006

On Declarative and Dynamic Programming Languages


James McGovern raises some questions about Declarative and Dynamic Programming Languages in a recent post.
Comparing dynamic programming languages to declarative programming languages is akin to revving the engine on your Minivan next to the Corvette at the Red light. The real question is have we selected the right tool for the right job. Just because any good handyman can turn a Phillips head screw with a flat-head screwdriver...does not mean you should.
I, as with anyone who has coded, will acknowledge the strength and efficiencies of well written code over declarative languages and output from Evil Wizards. Productivity is only one aspect of the equation though. I am vigilant proponent of Business-oriented automation. In certain circumstances, enabling business-oriented users to modify business assets using tools such as Business Rules and Content Publishing systems IS the most productive approach.
The key to bear in mind is that the business customer must accept the investment of IT resources to steward the SDLC and any supporting technologies around such business-oriented systems and their front-ends.

Thoughts on EA Cynicism...


Scott Mark posted some brilliant thoughts on Enterprise Architects and their propensity for being cynics. I wonder whether or not the concern is less about feeling undervalued and more about wishing that they sovereign domain and discretion over the IT portfolio. What would a good architect do if they owned all budget and timeline decisions? Maybe corporations should have an architect "King-for-a-Day" day. Seriously though, Scott's post is very timely in that a group of architects I was with just today had a discussion on a nearly identical topic. There seems to be a pattern of the importance of architecture and the profitability of the business customer we support.

I submit that the ability to speak in business terminology should be a prerequisite for most architects. If you cannot communicate with your business customer, you should not be consulting with your business customer directly. Project managers play a key role in articulating the planning details, financial implications, resource requirements and timelines of project work. As I posted before, a healthy tension between project managers and architects is a good thing.

Further, Scott discusses the importance of "demonstrating the value of EA through participation". I would offer that marketing IT is critical in most IT leaders' minds. James McGovern has posted on this as well. In the end perception is reality.

So what's the answer? I am landing on a more mature viewpoint on marketing technology and architecture. Its a Band-Aid to trust problems or process issues. Don't get me wrong, I think its critical that success be celebrated. I do however feel that through empowerment, architects will internalize and declare themselves accountable for righting wrongs. Suggestion boxes, covert meetings with business decision makers, and financial incentive/disincentives are NOT the answer. Do we really think we have the one best answer to all problems if money, tools, timelines and resources are infinite? Should our customers be asking us to build Web Services and ESBs? Perhaps the real issue is that we spend too much time justifying technical details and not enough time demonstrating impacts to the bottom line and modeling new business functionality. Often times the best critical decision-making happens under pressure. If the business needs a economical commuter car and we engineer a Ferrari--we fail. If the business needs a strong truck and we deliver a quick and cheap Pinto--we fail. Every architect and customer must understand the REAL business problem and functionality we are solving for...in absence of that we have the potential for either designing too tactical or over-investing in undervalued capabilities.

Architects develop some cynicism based on missed opportunities and mistakes of the past. In order for one to have success with architecture and improving the IT portfolio, one must love it a little and understand it a lot.

What do you think?

Tuesday, April 04, 2006

Architecture Team...The Reformation...



I have had conversations with IT leaders in 4 different companies recently and they all shared that they are going through some form of reorganization. I find it interesting and oddly coincidental that this trend is going on.

This reformation of architecture can have some significant benefits:
--> Increased architecture awareness
--> Realignment of resources in a way that better meets the emerging IT demand
--> Increased propensity of the architecture team to drive change to the portfolio
--> Common techniques for measuring value and assessing new work
--> Change always broadens experience and exposure to new problems
into the IT Portfolio
There are risks too:
--> Identity crisis
--> New onboarding process
--> Distraction from current expertise
--> Misperceptions from customers
What I am interested in hearing from the community on is this:
Is your organization realigning the architecture model?
If so, why?
Are you driving the change internally or working with a consultant/integrator?
What insight can you share?
I look forward to your comments!