//September

Washing fences

By |2007-09-08T23:22:00+00:00September 8th, 2007|Enterprise Architecture|

Quality is a skill.  We need to teach it to our children, just as assuredly as we teach responsibility, compassion, and honor.  At work, we need to both embody it in ourselves, and encourage it in those around us. 

I was a SDET for a while.  That’s Software Development Engineer in Test.  I wrote code to test other code.  I never expected my code to see the light of day, and it didn’t, but the code I tested saw millions of computers, and I was proud to be part of the quality cycle.  As an Architect, that ethic is more important than ever, because it is more difficult to detect ‘bugs’ in an architecture.  Quality has to be high when no one is ‘testing’ you.

I spent the day, today, working in the yard with my oldest son, Max (It’s a time-honored tradition in a suburban neighborhood, to spend inordinate amounts of time working in the yard ;-).  Part of the work involved taking a pressure washer and scrubbing years of dirt and grime off my cedar fence.  It’s messy work and if you miss a spot, it shows.  Another task was taking a hand clipper and carefully grooming a hedge between our house and a walkway to a neighborhood park.

Max is just a few weeks from his 14th birthday, a tall, lanky boy with a sweet smile.  He’s pretty typical.  Loves video games, and hanging out with his friends.  He’s growing fast.  But his approach to work is pretty much “do as little as you can to get the work done.”  The output can, at times, appear a bit sloppy.

So I spent the day teaching.  Sure, we were doing yard work, and the hedge looks much nicer now.  But more importantly, I hope that Max comes away from today with a greater appreciation for quality. 

Quality is the art of standing back, looking at a job through another person’s eyes, and judging it as they would.  It is the art of finding the imperfect and deciding if it should remain.  It is a kind of pride: pride in a job well done. 

For me, quality is related to honesty.  If I believe that something is truly good enough, it is because I believe it is an expression, as best as I can muster, of the truth.  I know that sounds esoteric, but there it is.

At the beginning of the day, Max worked to make me proud.  By the end of the day, I think he was working to make himself proud.  I hope so anyway. 

He did quality work. 

SOA drives an odd data model

By |2007-09-08T01:42:00+00:00September 8th, 2007|Enterprise Architecture|

Information Architects are an interesting crew.  Take everything you know and love about a person who “thinks” in data, add layers of set theory that you haven’t looked at since college, throw in a pinch of realism, a flair for idealism, and an ability to generalize things that you didn’t think could be generalized, and you get an Information Architect. 

But sometimes, that way of thinking can lead you astray. 

If we are to create an Enterprise SOA, with services that are both independent and composable, we will not succeed unless those services surround objects that make sense to the business.  Sometimes, when you generalize too freely, you create an object that cannot be understood by the business.  And while you can store the information, efficiently, you cannot manipulate it independently.

Take the concept of an invoice.  It has a header and lines and information about products.  Looks a lot like a purchase order. 

An average database engineer may tell you that you can create a table for the invoice header and put in a status flag or two.  Then you can store both invoices and purchase orders in the same structure.  Some information architects would agree.

SOA thinking says “no.”  If you are going to build an independent service, then you have to seperate the logic between services, so that there are no side effects between them.  It is nearly impossible to insure that there are no side effects between services when they store their core data in the same data structures.  Especially when you consider the temptation to place logic into stored procedures.  While you don’t have to create one set of stored procedures for one table, there is nothing in a normal database system to prevent it.  Complexity creeps in.

To seperate the logic, you have to have a good partition to seperate it on.  As any information architect can tell you, the number of different ways to represent something is close to infinite.  So you have to decide what things need to be stored, and represented, in seperate ways.

So when you are busy creating your data models, remember not to generalize too much.  If you are tempted to combine two entities, consider this: if different people create or manipulate those objects, or they have different lifecycles, resist the temptation.  Keeping things seperate on the basis of roles and processes is a good thing. 

It’s a good way to keep your independent services… independent.

Replace SOA Governance with SOA Marketing

By |2007-09-07T09:10:00+00:00September 7th, 2007|Enterprise Architecture|

Many of the SOA marketeers have grouped around the notion of SOA Governance.  I have a bone to pick. 

For the sake of public discussion, let’s pull apart “governance” into some buckets… and then attack one of those buckets.

  • Bucket 1: EA Governance – This is the review of funded initiatives to insure that the IT components are aligned with business objectives.  This is useful, and in fact, is often a defining function of the Enterprise Architecture team in many organizations. 
     
  • Bucket 2: Information Security Governance – This is the review of delivered code to insure that it protects corporate and individual information assets.  In modern companies, the risk of not doing this is high.  Web services offer an interesting interface for attack, and therefore, must be accounted for in any security reviews.  This is essential.
     
  • Bucket 3 – SOA Governance – this is a design review, either before or after code is developed, to insure that the integration services meet particular technical and informational requirements designed to support integration goals.  This includes insuring that canonical schema are used (and used correctly), that correct namespaces are identified, that the services use particular patterns for message exchange, that they are hosted, tracked, and managed in a consistent manner.  All of these are useful exercises from the standpoint of operational efficiency and enterprise control.

Of these three, I have listed them in order of importance.  Yet they are in reverse order of tool avaliability.  In other words, there are more tools available for the least important than there are for the most important. 

In fact, I’m going to suggest something radical.  Let’s not do the third.  Not as “governance” anyway. SOA Governance should be replaced with SOA Marketing.

Governance is a mechanism to enforce a particular set of behaviors.  Marketing is a conversation that  collects customers needs, crafts a product to meet them, and then informs the customer of the advantages of using that product. 

We need IT teams to choose to follow standards and conventions, not because some geeks in another team say so, but because it is less expensive for the projects if they do.  To make it easier, we need to listen to their needs.  We need to build a product to meet those needs.  We need marketing, not governance, in this space.

At the optimum, we want compliance with SOA standards to be optional yet ubiquitous.  When an electrician wires a house, he uses standard outlet fixtures.  In many cases, house inpectors care if the house is safe, not usable, so they won’t complain if he used non-standard fixtures… yet he uses the standard… why?  Because it is cheap, easy to do, and the customers like the results.

That is the same reason that SOA service developers should give when you ask why they stuck to the standards.  It was cheaper and easier and the customer preferred the result.   

They should not say: “Because the SOA Police told me to.”