Southern BITS of Technical Goodness

Our business has grown quickly, from $1M in annual revenue a few years ago to almost a hundred times that now. In that time, I’ve moved from web based Java development to .NET rich client development.

The company I work for has used client server applications that use Access front end with a SQL Server back end. Access is written in VBA using forms over data in a procedural programming model.

I’ve argued the value of OOP and best practices, but my success has been gated by one thing: SPEED TO DEVELOPMENT. Why?

IT (geeks) provide what value?

I used to believe we generated profit. I used to measure my value in added revenue, but soon I realized that upper management sees IT as a cost – waste. Their goal was to minimize cost and maximize profit (or in a LEAN way of thinking, reduce waste).

IT is WASTE – we are an expense not revenue.

Don’t believe me? See your paycheck for proof. I hate this idea, but that’s the way that upper management often sees us (geeks).

So consider the two perspectives that geeks and business have. We see this:

But business owners see this:

As Dennis Hopper said in True Romance If that’s true, am I lying?

So what are you (GEEK) going to do about it?

We’re right. We know we’re right. We can’t be wrong. Right?!

So why in the hell are they saying big gray blobs and BIG dollar signs when we want them to see…

How to do that:

1. Reference prominent companies (& geeks within) that use best practices. Business values experience and most importantly they value SUCCESS & FAILURE. If you can show that following good practices is what successful companies do, and that unsuccessful companies have failed for not following best practices.
2. Does business want it RIGHT or right now? Software projects fail. They have failed time and time again. Getting software implementations right takes time. Moving too quickly only results in failure and rework. You can only move as fast as possible but no faster (see Einstein: Make things as simple as possible but no simpler).
3. Ask questions: Is this a long term investment or short term? If business is seeking a POC (proof of concept) or the financial/business climate is such that they need to prove something out or “just get it done” then perhaps fast is best. But if the project is a long term investment, then they should do it right. Pay upfront for good architecture, project methodologies and infrastructural support.
4. Be Reasonable. Understand business. You want business to understand you, but you need to understand business. Why should they care about your best practices when you don’t give a damn about their profitability or time to market. Remember IT is an enabler – IT is waste, help them reduce waste.
5. Best practices lead to flexibility & more responsive, cost effective solutions: Face it, best practices are going to cost more to develop. Forms over data are fast. MVP / MVC / MVVM with repository patterns and asynchronous enterprise service buses mocked out and developed using TDD just take longer. So why would business want that? If you don’t have an answer, don’t expect business to buy in.
• Design patterns increase flexibility which allow IT to respond faster to business.
• Test Driven Development decrease mistakes and bugs and leads to automated regression testing (decreased testing costs)
• Electronic Service Buses formalize application boundaries which allows business to swap out new technologies, vendors and applications as they become available thus decreasing cost and increasing IT responsiveness.

Summary:

If you can’t sell what you believe in, then you need to work on the pitch. Being a geek doesn’t omit us from having to persuade people to accept our beliefs.

IT is a sort of religion. It’s mysterious, poorly understood (even by us), and we constantly are trying to understand a thing that is far greater than ourselves – something we’ll never fully comprehend.

In the end, all a geek can do is convey what we believe in using the language of business.

alan.huffman Architecture, Business, Business Growth, Development Infrastructure, Projects Best Practices, development, leadership, management

Summary:

My company required a data driven Work Flow that was generic enough to handle all long running and synchronous business processes. Since I built most of this at home ( I never have time to actually develop projects at work ), I feel liberated to blog about my experience.

High level business requirements were:

• Generic
• External to all applications
• Data Driven
• Quick / Easy manipulation of business rules

High level Technical requirements:

• Fast / easy development of workflows
• Abstracted Data Schema / Model
• Distributed work flow using web services (WCF)
• Asynchronous transitions
• Enterprise Scalable

Here is an example work flow I used: 
 

Before going into the details of the Work Flow, let me outline the

Development environment:

• Language: C#
• Application Platforms: Services, Winforms, WPF
• OS: Windows Server 2003, 2008 & XP
• DB: SqlServer 2005
• ORM: LINQ To SQL (DLINQ)
• WebService Technology: WCF [ HTTPBasicBinding & NETTCPBinding -- though can support any WCF binding protocol]
• Visual Studio 2008 SP1 w/ Resharper 4.1
• Source Control: SVN w/ Tortoise SVN
• Build Server: Team City
• Unit Testing: NUnit & RhinoMocks
•  
  

  Aside (DLINQ/LINQ To SQL Concern) One of my concerns was that LINQ to SQL (DLINQ) would go away [ be deprecated ] in lieu of ETF (Entity Frame Work). I would have used ETF, but LINQ is so simple and has lazy loading — ETF has an unsavory way of doing this. I’ll move to ETF in the future, but for now DLINQ rocks.      So to decrease the risk of DLINQ going away, I used a strategy Bryan Hunter from FireFlyLogic.com introduced me to. Essentially slipping interfaces in front of the LINQ Datacontext and, in my case, exposing my EntitySets as IQueryable<Entity> lists off of a repository pattern. (I’ll try to post this idea as “Unit Of Work”)

Basic / High Level Architecture:

The workflow is to be used across the enterprise and load would grow in time. So it had to scale up. To support this the participating components of the Workflow had to be able to run in parallel. There are three main components to the workflow:

1) Workflow Servers : Responsible for transitioning from tasks.

2) API’s : Programming interfaces for external clients / applications to interact with.

Our company has a legacy Access/ADP system that is widely used. In order to allow this system to consume / use the workflow, a database/stored procedure API was created along side the WCF/WS API.

3) Resources : These will be discussed later, but are the building blocks of all custom workflows. They are exposed over Web Services.

Brief Definition of a workflow

Workflows definitions can be complicated, but here the most basic unit of work is a Work Item which is the intersection of three things:

1. Case: The item / entity being worked on. (ex: A Customer)
2. Task: The action to be done (ex: Make a sales call)
3. Resource: The thing/entity doing the work (ex: Employee or the IVR (interactive voice recognition) software making the call.)

A work item is the intersection of these three items (ex: The IVR System will make a sales call the customer) or (ex: An employee will make a sales call to the customer).

Task transitions: A Task has outcomes that optionally transition to additional tasks (ex: Call customer, if they do not answer (outcome), make second call in 2 days).

A Workflow Definition is nothing more than tasks joined to each other via outcomes / transitions. (ex: [task] Call the customer, [outcome] if they do not answer, [task] make second call, [outcome] if customer is interested, take order [action], if customer pays [outcome], send order [action].)

Using Workflow occurs when work items are created based on outcomes. Not all potential tasks / work items occur (ex: if the 1st sales call is successful, the 2nd sales call never occurs)

Here is an example workflow that attempts to sell *something* to a customer. A sales person or IVR (resource) calls (task) the customer (case) trying to get an order. Call up to 3 times, if the customer can not be contacted, send them a mailer. If the customer is interested, take the order and upon payment, send the order.

Let’s do some code!

Simplicity was the key to design. All consuming programmers (those building workflows) should have to develop as little as possible. The framework should take care of the complexity. So what does must be built?

Workflows are built of tasks, but resources are the programming behind the task. A resource is constituted of 3 interfaces:

• ICreateWorkItem – (optional) creates the work item given a case.
• IValidateTransitionToWorkflowItem – (optional) validates that the case can be transitioned to this task & create subsequent workitem.
• IDoWorkItem — (required) responsible for doing the task/action.

These interfaces had to be simple, so they are:

[ServiceContract(Namespace="http://workflow/2008/03")]
public interface ICreateWorkItem
{
    [OperationContract]
    WorkItemData CreateWorkItem(WorkItemData wd);
}

[ServiceContract(Namespace = "http://workflow/2008/03")]
public interface IValidateTransitionToWorkItem
{
    [OperationContract]
    ValidateResultData Validate(List<CaseData> cases);
}

[ServiceContract(Namespace = "http://workflow/2008/03")]
public interface IDoWorkItem
{
    [OperationContract]
    WorkItemData Do(WorkItemData wi);
}

What is required to actually define a task? As with many Domain Specific Languages (DSL), I chose XML. Here is an example of a task definition.

<!– ######################### –>
<!– ## 1st Sales Call ####### –>
<!– ######################### –>
<TaskNodeDefinition >
    <Statuses>
        <Status IsInitial="True" Name="NotCon" Desc="Not Contacted" />
        <Status Name="NoAns" Desc="No Answer" >
            <Task Name="2ndCall" Validation="False">
                <DueDate Type="delay" increment="days">2</DueDate>
            </Task>
        </Status>
        <Status Name="Yes" Desc="Yes, purchase." >
            <Task Name="TakeOrder" >
                <DueDate Type="now"/>
            </Task>
        </Status>
    </Statuses>
</TaskNodeDefinition>

And that is all it takes. Define each task w/ the appropriate XML and implement necessary interfaces, and a workflow is only a few steps away. The framework deals with persistence, transitions,  scaling and reporting.

alan.huffman Workflow and Business Rules Business Rules, C#, TDD, Tesk Driven Development, WCF, Work flow