Nobody needs asset management like Sabre Systems, Inc–a hot-shot, technology enabling consulting firm. Sabre Systems is fueled by the  magic of technology in that they have found a market in collaborating with their clients to inject technology to solve business problems and to build and maintain competitive advantages.

Due to the nature of their business, the firm has “assets”–computers, servers, notebooks, etc–scattered across the country which has become a nuisance to manage.  In an effort to phase out the glorified spreadsheet that logs these assets, they’ve asked a group of four rock stars from Temple–including myself–to build a web-based tool to manage each assets’ information.

About the Tool

The information the tool manages include the following:

• locations,
• status,
• contact, and
• purchase information–

and specifically how each item relates to an asset.

Management is a word our group has been using to describe CRUD operations–Creating, Reading, Updating, and Deleting.  To put it in perspective, some of these functions would include listing assets of a category, assigning an asset to a contact. archiving, and creating an asset, etc.

About the project

All the information about an asset will be stored on a database and a web application will be built to interact with that database.

Each asset will have basic information–an ID, category, description, owner, and status–as well as some additional information including purchase info, pictures, warranty info, and file attachments, etc.  The application will also handle admin levels–restrictions to certain functions–and event logging.

The value of this project is that our group is working through the System Development Life Cycle (SDLC)–analysis, design, development (our current state), implementation, and minor to minimal maintenance–to develop a system.

Pushing the scope of class

This is what this project is all about.

From the very beginning we have found ourselves doing more than just building another web-application–like the ones for class..  Part of our planning phase included creating a development environment that mimics Sabre Systems’ production environment–which they happen to be a Microsoft shop.  To support all the functionality–including category assignments and change logs–our database has become exponentially more complex than any other database any of us have worked with before.

Here’s some more things that I’ve learned about and implemented in practical situation:

Database Recursion

This almost made my head explode, but I understand it now.

For the non-database people, recursion is used to create a “tree” of information; for example, consider categories with subcategories where a subcategory has all the same attributes as its’ parent category–possibly including another subcategory.  This is probably more confusing, so we’ll save this concept for another day.

We are using recursion to manage the categories that an asset can be assigned to–ie Desktop PC > Dell > Optiplex > 745 > Asset # 234.

Microsoft SQL and Microsoft Management Console (MMC)

In class, we learn Oracle at the command line.  For non-database people,  MS SQL, Oracle, and mySQL are all different flavors of databases–they are fundamentally the same with slightly different keywords and syntax.

MMC is a graphical user interface (GUI) that Microsoft created to interact with SQL (Access on steroids)–you can drag and drop different boxes to create relationships and even to create queries.  Think of MS-DOS (the command line) compared to Windows Vista (the GUI); it’s kind of a pain at first, but ultimately it can help.

Nested Queries

A nested querydoes 2 things: (1) it runs a query to find a variable and then (2) runs another query using that variable.

We are using nested queries to update our bridge tables that are logging changes.  We run a SELECT query to find the id of the record that needs updated and then an UPDATE query to update that record.

This is covered in class-briefly; but it’s nice to use this in a practical situation.

Left, Right, and Outer Joins

In class, we are taught implicate inner joins.

When values are called using inner joins, only values that are joined will be returned. Let’s say we wanted to call all assets and their status.  If we used an inner join, only assets that have a status assigned to it will be returned.  Now every asset should have a status–so it should not be an issue.  But, let’s pretend something went wrong and an asset lost its status assignment.  Using a Left or Right join you can populate all the assets-regardless of whether or not they’re assigned a status. Left and Right joins are functionally the same; the difference is in the order that they appear in the query.

If you used an Outer join in this example it would show all assets (regardless of whether or not it has a status assignment) AND it would show all status options (regardless of whether or not the status option is assigned to an asset).  For this project we’re using only Left and Inner joins.

Stored Procedures

A stored procedure, in layman terms is a database query saved with the database; it’s good for separating the business logic from an application’s user interface. Sabre Systems prefers stored procedures over queries to interact with their database for two reasons (two that I’ve been able to identify):

1. The cascading effect of any updates–so if they decided to add any fields or alter the outputs they only need to adjust the stored procedure.  Alternatively without stored procedures, they would be updating every single instance the application calls the database.
   I use the word cascading because a similar and much simpler concept to understand is Cascading Style Sheets (CSS) where you can adjust the style sheet of your website to adjust the output of your entire website.
2. If they decide to rebuild an application–let’s say Sabre Systems wants to integrate two existing systems–they only need to rebuild the “view level”–the user interface.   Ideally with the stored procedures saved in the database they would not have to rebuild the business logic that is running the application.

Needless to say, I’ve stepped up to be the resident database nerd/expert.

Navigating the System

I like PowerPoint.  Here’s a little presentation Taahir and I put together to show Sabre Systems.  Of course, we explained everything as we walked through this, but you should be able to pick everything up from the text.

Download the PDF: Asset Management – Phase I

What to expect

I’ve been playing with words.

Our group has been calling this an asset tracking system and today I have decided to call it Asset Management.  I’ve seen some astonishing correlations with this project and some other information “management” tools.

Look out for a future article detailing the relationships between Asset Management, my Project Management Tool (Planning My First Plugin), and Content Management.

The theme is [insert object here] Management and the topic is Management Information Systems (MIS)–the goal is to close the gap and explain these less than obvious relations..

More more information on Sabre Systems:  http://sabresystems.com/