Archive Group IV : Foundations of Application Development

Beginning Systems Analysis

5/8/2008 10:37:37 AM

  Blame my particular form thinking but I like to deal with business issues surrounding the IT industry.  By nature, when I see a problem or potential benefit area I look for ways to either solve the issue or to act on the opportunity.  Most times it is a good thing, others it just becomes 'Tilting at Windmills'.  It is fun and entertaining in any event.  (Keep in mind that my version of fun may not directly corrispond to yours, or the dictionary)

  With Application Express, XE, SQL Developer, and any number of other tools, our community has come to a point where the ability to attack a business need has definitly increased.  The APEX platform gives us a very concise and easy to learn Rapid Application Development environment to not only create an application but to quickly realize the benefits of that effort.  I came to APEX, html-db at the time, community when I saw that this was the type of system that could solve a lot more than just one or two issues.  I saw the potential to reap benefits that I previously would spend days and weeks just formulating the design for in other tools. 

  So since anyone in the community already knows this stuff why am I re-iterating it like a broken record?

  Without using any cliche, or attempting to do so, my observations of late have been that there is a whole lot of talented developers that can build just about any functionality into an application that one might desire.  There are books on how to do this.  I own more than a few of them now.  What is missing in all of this is the idea that systems development begins before you actually write code or build pages.  APEX lends itself very well to build first methods, but in this sense it becomes increasingly easy to build an application that is obscure, inflexible, and/or unsupportable.  This is the same with any tool you use and you can certainly do worse in most cases with other, hard-coded, systems.  Without some base thought processes and documentation, a new developer has a higher risk of losing their way or not being able to pull apart a broken component to analyze it and fix the issue.  Another fun result is that the progression of application developement is pretty predictable as the APEX platform evolves and as the individual developer increases in skill as well. 

  This topic is designed to cut the process of evolution short and get developers on the right track to defining and building applications that are scaleable, flexible and flow in such a manner that they become almost intuitive.

Comments

Process, Procedure and Flow

6/6/2008 9:50:59 AM

Continued From: Beginning Systems Analysis on 5/8/2008

  Whatever name you or your organization uses for this item, the foundation of a business data system is the Business Process.  Just about every application that can be concieved has a process of use that is associated with it but the underlying difference between a utility application like a "DVD Catalog" and a business App is that the process that drives its use is more than just the process to use the application itself.  So the Business Process is the first key area that has to be analyzed when attempting to build an Application that fills or automates a business need.  In some cases the process that is originally mapped is the old process that involves all of the hand-offs that many different functions will contribute to.  Mapping the process can be done any variety of ways from note pads to tools designed for process modeling like MS Visio or others.

  Recently I had the opportunity to go over a version of a process that I had seen in several organizations that centers around proactive safety and hazard mitigation and documentation.  This discussion goes back to the previous series on early adopters and such where the person detailing the process was, by every definition, very passionate about the activity and the surroundng circumstances.  By the way it was also a good refresher on how to tell a salesman from an advocate (or Evangelist), the salesman could never sound that kind of sincere without also being an advocate.

  So the discussion progressed and along the way I took abunch of notes on the steps involved in this particular process.  It is not that complicated, but then again the best trips from one point to another are the ones that make sense and don't go into too many twists and turns away from the end goal.  So here is the first an most common process model that comes from those discussions. 

  The things that I notice from this initial SWAG at the process is that while it is intuitive and follows a logical path it really does not tell you about the other elements tha make building an APEX Application, or any other for that matter, easier or more intuitive.  An information system is often defined as being a collection of Processes, People and Data System that achieve a goal or set of goal through integrated interaction.  So we have the process but now we need to find the other things involved.  So this is the next evolution of my process diagram that is more commonly referred to as a swim lane process flow.  It defines the lanes that represent the responsibile party to the activity or decision in the process.

   Now I have the people and the process that is happening now.  So all I need is to understand what data systems are currently interacting with the process and at what points.  What I know is that the data managed is largely captured on a small card that is roughly the size of 1/4 a sheet of paper.  It is double-sided and has a number of items in the form.  There is other data involved as well but this card is the initial point of entry when data is captured. 

  For the initial stages of good systems analysis and design the documenting of the process flow for the current state is essential to understanding what changes need to be made to improve and automate the process in the to-be state.  When you map the initial process keep an ear out for points of pain from the customer.  But make sure to document what the process is in the now so you have a basis to adress those issue in the next stage.

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with poting a thumbnail with a link to the file instead.

Comments

- 6/6/2008 11:05:30 AM

How long did it take to get that process in place and documented?
I know a bunch of companies that don't know the process ;-)
Great stuff Jason,
Dimitri

Jason Aughenbaugh - 6/6/2008 12:05:34 PM

This process took all of about an hour once I found the right kind of person who knew the process in question.  When there is more than one group involved the documentation of the process can take longer but if you find a way to get everybody in one room and are a good facilitator you can accomplish a lot in a very short time.  That said the time to get documented depends on who you have access to and how willing they are to walk you through the information.

Process, Stakeholders and More, oh my.

6/12/2008 3:29:31 PM

Continued from: Process, Procedure and Flow on 6/6/2008

So far I have tried to explain that the process of business is the foundation of any type of application that can be built for that business.  There is one more tool that can be very useful fo this evolution of designing and building your application.  It is called a SIPOC.  Not to be confused with Sybok.

What is the SIPOC?

When you look this term up on the net you are going to find a number of references to Six Sigma, DMAIC and such.  Trust me it is really not that complicated.  One of the best references I have on this item is here: http://www.isixsigma.com/library/content/c010429a.asp

SIPOC is an acronym that literally stands for (S)uppliers, (I)nputs, (P)rocesses, (O)utputs, (C)ustomers. The reference comes from a method of process modeling and analysis that seeks to organize this information into one place.

Typically the SIPOC guidance will usually tell you to take a high-level process for this type of analysis but it is also useful at a more detailed level. At this level where the process is broken down into it more or most basic for you can see the interactions of people, process and tools, like data systems

For your pure enjoyment, or a reason to laugh at me.  I cleaned up my SIPOC utility and put it HERE with the items for my previous process drawings in it.  I also had to post another drawing with the corrisponding numbers for the process references.  It is built in APEX which was built in APEX and helps me to build applications in APEX too.  Circular Definition, anyone?

 

Anyhow, I find this tool really cut to the chase in determining the process and the key elements about the process and its users.  When you take this items to a good level of detail the system interactions with the process and the people involved really have a way of standing out and it make the task of designing the application and the underlying datamodel a bit easier and more consistent.

Updated Note:  Please keep in mind that the SIPOC Application has an output that I was still experimenting with and haven't yet perfected.  Also, feel free to add your own rows and see how this (very basic) application works. jda.

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with putting a thumbnail with a link to the file instead.

Comments

bagslead - 3/23/2009 10:56:21 AM

this article is very useful for me ,thanks for sharing.
http://www.bagslead.com