Workflow foundation: new capture. SSIS: existing capture

Per my previous post on the two faces of business intelligence, I'd like to further my point by describing two "core" technologies from Microsoft: Windows Workflow Foundation (WF) and SharePoint Integration Services (SSIS).  These two technologies in my opinion are "big" in the sense that that "orchestrate workflow".  Let me explain.

Windows Workflow Foundation is a technology that allows a developer to "map out" a business process and wire in the user scenarios to capture--and then store--the data.  The important part here is that we are going from nothing (the user's mind) to something (the database).

SQL Server Integration Services (SSIS) is a technology that allows a developer to "map out" an in-memory data transformation process.  The important part here is that we are going from the database *back* to the user's mind (typically in the form of reports or other data visualizations).

I think the interesting thing to note here is that these two technologies are *so* similar.  They depend on tasks, create flows, etc., but are not really integrated in any real way.  Is one a sub-set of the other?  How do we think about these two different--yet very similar--technologies.  Do they fit within the same developer toolkit or what?

As a solution architect you have to be aware of these things.

Interesting related reading and reference:
http://www.developer.com/db/article.php/3780676/Building-a-Windows-Workflow-SQL-Server-Integration-Services-Activity.htm

An Easy-To-Follow, Scalable, Agile Process for Anything

In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way).  I think you'll find it useful and informative.  It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results. 

1. Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested.  Make sure you include who its from and anything else.  Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow.  Don't let yourself or the process be the bottleneck!
   
2. Backlog and prioritize this work.  Figure out where the request should sit in the queue.  Use a method like FIFO or LIFO as a reference.  You could also create a "value index" to score the cost/benefit of the request.  Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
   
3. Define the request in concrete terms including the problem, required output and success criteria.  This may also include the specific implementation method and input required to get the job done.  Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
   
4. Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary.  Remember the goals and make sure there is no "loss" in the communication process. 
   
5. Assign the work and start executing.
6. When the work is reported to be completed to spec by the person, verify.  Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
   
7. You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well.  Queuing your results will promote longer, larger cycle times but could be more efficient for your business.  Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
   
8. Deliver the result to the end customer.  This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.

I hope you found this process for getting things done useful and are able to apply it to things in your life.  Please offer any feedback or questions to me through the blog or to eric.veal@efficitrends.com.  Thanks!

Developing the Right Metrics Matters the Most

There are several ways a person could view an organization:

• As a collection of business processes (activities) that the business has to perform to meet its strategic objectives
• As a collection of IT applications that support the processes
• As a collection of people and suppliers who provide the resources necessary to achieve the organizational objectives
• As a collection of metrics or measures that describe the performance of the organization

Although each of these perspectives is equally real, only one is RIGHT in my opinion. Which one? METRICS, I say. Unless we boil our organizations into numbers and shared things that people can understand -- not complex and changing things like systems, processes, tools, and people -- can we really manage our organization as a program. I'm not making an argument for ACCOUNTING, per se, I'm talking about those facts and figures that tell us whether or not our business is being successful at achieving its objectives.

Therefore, it's my contention that a key part of the strategic planning and communications processes is to define and communicate about the key performance indicators (KPIs) of your business. KPIs are a bit of a cliche term but they're critical. The fundamental question we have to agree upon is, "How will we know that we are doing well?".

The more we develop this language of numbers and measurement, the more clear we will be together on our perception of what matters and how to allocate our resources and attention.

Business Process Engineering and Business Intelligence

Two buzzwords. What do they mean?

To me, BPE is all about changing the way the organization uses its resources; seeking to improve efficiency, cost, quality, and time. It generally uses IT but IT is not the only tool it uses. Other tools that BPE uses include: re-organization, training, and good internal communications and programs. This is my favorite topic, and I think the most important one for business: How are we using our resources and how can we better use them through the adoption of technology.

Business Intelligence to me seems way more vague and stupid than BPE. One way to look at BI is through the lens of Six Sigma: Define, Measure, Analyze, Improve, Control. I think that BI is about Defining systems that create Measurements and then Analyzing what's going on in the hopes that the system can be Improved and Controlled. BI gets into designing measurable systems so they can be controlled. That's all.