Monday, August 2, 2010

How is Domain Driven Design relevant to today's corporation?

Domain Driven Design; Is an implementation approach, as part of a larger delivery process. It specifically focuses on the importance of concentrating on Business Centric Design and the economic value that can be achieved by decoupling the specific technology implementation from the Business Domain and Business Rules.


It further creates a framework for reuse within the enterprise; a significant amount of time is typically spent on Business Domain and Business Rules analysis and development.

The future of DDD focuses on Domain Specific Languages and code generation; again the economic value of above becomes apparent quickly.

Saturday, November 21, 2009

Technology Debt?

Technology debt is real - and yes it has to be paid back. The challenge is 'how can the industry standardize or formulate a measure of Technology debt. Technology Debt encompasses the cost to the business, impacting new systems as well as the operational costs for existing systems.


An example – An insurance company decides to venture into a new market based on tremendous potential and little competitor penetration. Time to market will clearly be a factor for delivery; budget tends to be hard to come by and the ROI models are tied to the annual shareholder objectives.  So the typical requirement to IT is to deliver all features within a specific timeframe at $ budget.

Common IT wisdom dictates that this is an impossible task.  MSF for example specifies that one of the constraints can be prime while the remaining two have to adjust.  Quality is assumed to be constant.

In the enterprise context, I would consider this to be an every day request/occurrence, which is NOT dysfunctional but which should be embraced given a proper framework for tracking the impact of this approach.

What I believe needs to be constant is (business) effectiveness. 

Quality and Risk Trade-offs:

  • Design
  • Architecture
  • Vendors
  • Defects per k
  • Operational Cost

There a multiple benefits:

  • Business Agility.
  • Delivering impactful business systems at lower initial cost.

Obviously the pendulum swings the other way once the market has been effectively served;  the battle for market share now tends to be prolonged and in small increments.  The push for efficiency now becomes important.

An organization that has tracked Technology Debt will have planned for the shift and can now appropriately communicate to Shareholders/Employees etc. why investment has to be made into systems.

Theoretically 'the perfect system' can be built eventually.
The perfect system never breaks and provides 100% business value 24/7 and the cost to create and operate never exceeds its value.

All prior generation systems attempt to meet the perfect system standard, trade offs define the actual system.

Ergo, the difference between the perfect system and the delivered system(s) is the Debt.
The future of Enterprise Architecture is now?

Martin Fowler’s perspective on Technology Debt - http://martinfowler.com/bliki/EstimatedInterest.html

To measure and apply technology debt, several dimensions would have to be taken into consideration, but I do think that the merits of tracking it would outweigh the costs. 

Wednesday, November 18, 2009

2009 Favorite Under-Rated Enterprise Technologies

Architecture & Process Modeling
  1. Enterprise Architect
  2. Eclipse Modeling Extensions + UML2
  3. Visio
Business Process Management
  2. Italio
  3. ILOG
  4. K2

Customer Relationship Management

  1. Anything Open Source
  2. SugarCRM

Enterprise Resource Planning

  1. Anything Open Source


  1. GoogleApps any flavor
  2. .NET
  3. PHP 5.1
  4. JAVA
  5. Ruby

Content Management

  1. Joomla
  2. MOSS
  3. Build-Own

Operating Systems

  1. Anything Cloud based
  2. Linux any flavor
  3. Vista Professional

Database Systems

  1. Big Table
  2. Myself
  3. SQL Server 2008
  4. DB2

Monday, October 13, 2008

Favorite Underrated Tools 2011

Architecture - Business and Technical
  • Enterprise Architect - product by a company in New Zealand
  • Microsoft Visio
Database Modeling
  • Enterprise Architect
  • Erwin ERX
Code Generators
  • Any
Business Process Management
  • PEGA
  • K2
  • .NET 3.5
  • ILogic
  • CIC E-Signature framework
  • Groove - Peer to Peer by Ray Ozz for Microsoft
  • MOSS/SharePoint
  • Microsoft Commerce Server

Most Underrated Delivery Process

Internet Speed Development - also called Microsoft Solution Framework, a no nonsense delivery process. I have personally used it commando style over the last 6 years with excellent results. It is loosely based on PMBok, shame it seems to loose popularity in favor of pure PMBok.

Favorite Code Review Tools

  • FXCop - Standalone and Visual Studio integrated
  • Reflector - Decompiler and documentation
  • Jungle Software Decompiler 2005 - Decompiler professional strength
  • FinRadFxCopStats - track FxCop remediation
  • NDepend - integrated code quality reporting tool