IT@Intel Blog

6 Posts tagged with the cost_savings tag
Click to view John Simpson's profile
2

It is vitally important to give data consumers an indicator of the quality of your information. This helps to build a trust in the completeness and review state related to what they are consuming. What we have implemented is real-time, includes embedded business rules and a pretty little display.

So what did we do?

  • Created a Five tiered rating system Data Quality(DQ) State
  • Moving through each tier means that data completeness and audited quality checks are performed
  • As the software application moves through its life cycle, additional data elements become mandatory, which effects the dynamically calculated rating
  • DQ State value exposed for interfaced consumption
  • Shown on-screen with graphical representation

What is involved in each DQ State tier level?

  • DQ State 0: does not meet minimum required data
  • DQ State 1: Name, Business Description, Status, Manufacturer, Owner (Group/Contact)
  • DQ State 2: State 1 plus - Host, Software Type, User (count/location), Data Classification, Technology categories
  • DQ State 3: State 2 plus - Cost Assessment
  • DQ State 4: State 3 plus - Capability categories, Network communication details, Business Continuity details

This tiered approach begins to define higher quality for the data completeness as it moves up the defined levels. Not only having the blanks filled in, but the application of embedded business rules-based analysis to validate content, drives the state calculation. These are updated based on any change to any of the evaluated content.

What do you do in your organization? How do you ensure that the data "freshness" is preserved?

Previous topics include Application inventory, what do you capture?, Application inventory starts with a definition, Application inventory as a cost savings initiative and Application Inventory, the start of data sustainability?.

2 Comments Permalink Tags: value, software_development, application_inventory, cost_savings, data_quality
Click to view Ilene's profile
2

Come join us!

The success of a security program is measured by an event that doesn't happen, so how do you know if you were successful? Matt Rosenquist, Intel’s Information Security Strategist will do a three-part series on Blog Talk Radio discussing the difficulties of measuring a security program.

Segment 1: May 20th at 10:30 AM (Pacific): The Problem of Measuring Security Part 1 of 3

Segment 2: May 29th at 10:30 AM (Pacific): Return on Security Investment - Intel Cast Study Part 2 of 3

Segment 3: June 4th at 10:30 AM (Pacific): Future State of Security Measurement Part 3 of 3


Our Blog Talk Radio segments are interactive and we will be taking live calls from listeners (Call-in Number: (347) 326-9831) and live chat over the Web.


What are your questions for Matt around security metrics?

2 Comments Permalink Tags: security, roi, rosi, rosenquist, information_security, matthew_rosenquist, cost_savings, corporate_security
Click to view John Simpson's profile
2

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition, and finally Application inventory, what do you capture?

Following the natural progression of:

  • Why inventory
  • Boundaries of what to capture
  • What to capture
  • How to capture

The "How to capture" is not a simple task completed in a week or two. For a company our size this task is still ongoing after fourteen months. And our progress shows us that we will need at least till the end of year to approach some semblance of sustainability. By sustainability I mean that the information, process and people will be in place to keep the data in a fresh state so that true data-based decisions can be made at near real-time.

Every day the clarity of our inventory gets sharper and sharper as we identify and pull in the data owners. The quality of the information becomes more focused as more of the profile is filled out. There are internal systems that are starting to rely on the data we have captured. That data is being transformed into true business information which has value and can be used to make the right decisions at the right time. At times, it still feels like an uphill battle. Each day we stand side-by-side with those who see the value and push on the back of our partners as we slowly progress up the hill.

Now knowing the definition and what data we want to capture we could have progressed in a multitude of ways:
  • Distributed work-load, individual owners
  • Focused work-load, our team owning (interviewing)
  • Centralized gathering (combination of above, driving people to a single location)

We chose to adopt the creation of a simple to use, centrally located (Intranet Application), that stored the data we needed. As mentioned in the past, we did our analysis by looking at applications on our enterprise that already contained the types of data we were interested in. What we discovered was that none of them had the flexibility to store the additional information nor the development resources to alter their systems. This pushed us to obtain permission to build a new application.

At this point you may be saying, "You built an application to reduce the number of applications?" Sometimes it is necessary to do the wrong thing in order to do the right thing. It would have been too easy to drop a spreadsheet out there and start gathering information. Short-term this would have cost the least and potentially would have allowed us to get part of the way there. The issue is the long-term sustainability and trust that comes from a solution like that. We would have security concerns, updating collision as well as the reduced ability to share the data easily with other applications.

Yes, we built a new application, using two people, in four weeks. Since implementation started we have supported weekly releases while expanding the data being captured, the usability for customers (and consumers) as well as enabling the removal of the majority of those other systems with parallel capabilities. We have great internal hosting solutions and have been operating non-stop since December 2006.

Our goal is still to do the right thing and properly manage our inventory through reduction. We were instrumental in providing the information and process needed to remove over 500 applications (and associated hardware) from our environment since we started our process.

In my next entry I will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with. Perhaps its time to start looking at how our original analysis for "Low Hanging Fruit" was successful and now we find ourselves making hard decisions in order to continue refining our inventory.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

2 Comments Permalink Tags: value, software_development, application_inventory, cost_savings
Click to view John Simpson's profile
0

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition.

In our specific implementation, we started with a base set of attributes. Some of those were very obvious while others were necessary for managing some of our base enterprise capabilities. Items that were only captured in a 1:1 (one-to-one) relationship to any single specific application were:

  • Name
  • Description
  • Importance (a tiered level detailing the impact to our company)
  • Status (or state of the implementation)
  • Type (of application)
  • Manufacturer (if purchased)
  • Version
  • Owning Group
  • User Count

We also had some 1:M (one-to-many) related attributes which we cataloged in order to further build out the metadata for each instance.
  • Contact
  • Cost (develop, host, support, license)
  • Link (to external data)
  • Support
  • Technology

This was sufficient information for us to move along and begin consolidating data. As we engaged more and more teams and discovered localized stores of this data, our metamodel expanded to include a few more elements. Some of these also included associated increase in our own inventory tool capability. As this capability was implemented we were able to start turning off applications through consolidation (one of our key goals).

Additional Items (one-to-one)
  • Product Line (for ease of grouping and management)
  • Hosting Platform
  • User Description
  • Cross-Site Consumption
  • Customer Located External (to Intel)
  • Data Classifications (for information security and control)
  • Disaster Recovery Details
  • End of Life Tracking (legal and recovery data)

Additional Items (one-to-many)
  • Alias (alternate naming; the key to our success)
  • Capability
  • Component/Module
  • Customer Country/Region
  • Interface (consumption and providing)
  • Network Ports/Protocol
  • Product Testing (results, for future enterprise releases)

Many of them are specific to how we do business inside our company, however, you might find value in some of our learning's.

As I mentioned we discovered pockets of data and some little (and big) applications utilizing some of this data. It has become increasingly easy to implement an additional module that relates and consumes the data from the larger metamodel. From an architecture stand-point, we need to be careful not to develop this into a "jack-of-all-trades" application that does everything for everyone.

Up to this point we still only capture data (and functionality) that is related to the Application through direct relationship. As an example, we associate the application to what network port/protocol it uses, but not necessarily the network that is can pass across. We will capture the hosting platform name but not the specifics of that host. Instead we rely on interrelated systems to draw the larger picture of the whole enterprise.

Are we done?
Not even close. As noted in our Intel Information Technology 2007 Performance Report (page 12), this application and the associated capabilities we are developing is having a big impact. During 2007 we were instrumental in the end-of-life of over 450 applications. The metadata we capture and maintain have helped to identity instances of duplicity as well as opportunities where support and consumption have dropped to the point we can turn off the application.

In my next entry I will talk about how we were able to use two people resources and build an application in four weeks to solve this problem. Also how that solution has been running non-stop, for fifteen months with no downtime or impact to customers while increasing capability and usability while doing releases on average of every two weeks. Future posts will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

0 Comments 0 References Permalink Tags: value, software_development, application_inventory, cost_savings
Click to view John Simpson's profile
3

Every software project I have worked on always started with some form of conflict and complicated interactions. This usually resolved itself through the use of a definition regarding roles and responsibilities. That definition kept people on the same page and helped everyone to understand who was doing what.

Now depending on when you happened to look at my job title over the last 13 years, you may have seen one of the following:

  • Software Engineer
  • Application Developer
  • Enterprise Application Developer
  • Software Developer

This means only that I moved from one department to another, however, the physical tasks I employed were the same. My output may have had a different installer/wrapper/output, however, it was the same. I designed, developed, tested and deployed an application into our environment.

When it was time to define the characteristic (metadata) of an application, we needed to start with definitions. Not only what an "Application" is but what "Software" is and how (if) it differs from each other and from an "Operating System".

This is vitally important because no matter who you talk to, they will have a difference of opinion in this area. Let me give you an example that we are currently dealing with. We are implementing a CMDB (Change Management Database) for our Service and Support organization. As our application data is pumped into that solution we had to decide whether it is an application or software. The CMDB definitions basically stated that software was the core items used to build a hosting platform whereas an application is the code hosted on that platform. A very specific definition for their very specific implementation.

Our definition was much more simple.
If it's coded, if you develop it, it is a software application simply referred to as an "Application". This can be developed internally or purchased. An application is not an operating system.
That means that everything running on our environment, that is loaded on top of an operating system, is an application and needs to be inventories. That also means if it is a web-based solution, with software code, hosted within a web-hosting solution, however, it is still an application.

We did draw a very discreet line in that we did not want to inventory certain things. Those are items that are "configured" inside of other applications. Item such as:
  • Web sites without dynamic content, hosted within a dynamic web solution such as Microsoft Sharepoint or created with Microsoft Frontpage or another WYSIWYG client.
  • Templates configured for an application.
  • Fileshare
  • Hosting Platforms (configuration of hardware and application software)

To put forth some simple rules, that people can evaluate their "Application" before attempting to add it for evaluation, we came up wtih some simple rules. It has to meet all of these with a yes response.
  • Installed on Intel (or contracted) hardware?
  • Initially used by more than one person (or application) at Intel?
  • Does this have (or has it ever had) a development/support team?
  • Does this have (or has it ever had) a development/release process?

This minimizes the possibility that we inventory applications that are sitting in a box, not installed on the environment. It also means that items we paid for, installed, licensed and such, are included. Whether on a server or on a client, we need to know about them so that we can work towards the simplification of our inventory.

Next I will cover how we have gone about gathering this data. Some approaches work well while others don't. Additionally, before you start gathering data you must have a solid review, maintenance and data quality processes in place or the data will be of no use for future analysis.

Have you undergone a similiar process? Are you struggling with doing this inside your company? Have questions? Let us know.

3 Comments 199,001 References Permalink Tags: value, software_development, application_inventory, cost_savings
Click to view John Simpson's profile
2

Fourteen months ago my (new) manager approached me with a unique problem. It was discovered that we did a very poor job of keeping track of the applications (software) that we build and/or install within our enterprise environment. This lack of tracking also included all the associated data related to hosting (hardware, configuration and such). That's not to say that some organizations inside our company weren't doing a great job, however, these pockets of excellence were the exception not the norm.

My (now) manager explained that a new group will be forming to help find opportunities to save money in the application and hardware space. His problem for me to solve was that there was no single solution, no one source for data, nor any single location for recording information. As a technical lead with several years of experience in metadata modeling and tracking, he asked me to go off and propose a solution.

As I mentioned we had several pockets inside the company that were tracking data as necessary to perform their job functions. After performing an internal environment scan, analysis and in several cases, engaging with the teams and their tools, I was left holding an empty bag.

What did I discover? There were 12 different applications (out of vendorprovided and internally custom built) and around 14 additional data sources(spreadsheets and databases). Through engagement, it was determined that of the solutions, many were on aged technology and some had lost their developers to other projects. Additionally, most of the existing inventories had only one small piece of the puzzle. They were only concerned with that one bit of information that solved their business need. This meant that enhancing an existing solution was not going to work.

So off to the drawing board I went to try and come up with a quick solution that would enable us to rapidly gather our application inventory, the right way, the first time. My proposal was taken to senior management and four weeks later, three of us had completed the first version of an application which is still in use and the Record of Origin (ROO) for application metadata within our company.

How does this all save us money?
Let me give you an example that anyone can relate to. Think of this in terms of an inventory of the food in your cupboards. If you go to the store without any knowledge of what food (canned, packaged, frozen or fresh) you have, how do you know what to buy? One of the kids may know you have some corn, another may know you have a pot roast, however, is the inventory accurate? Until you get into all your cabinets and do an inventory, you'll never know what you have. Additionally, without putting a system in place to maintain that inventory, the next time you make dinner, your list is completely useless.

Continuing my food sample, let's say you want to make a lasagna. How do you know if you have the ingredients? How do you know you don't have one already, frozen and ready to heat?

This is the problem we found ourselves in (applications not food). We had no idea if we had overlapping functionality. Our capabilities were meeting our (internal) customer demands, however, were we meeting that need at a higher cost than necessary? Were we asking people to use a tool that was outdated (technically speaking) when a newer, faster, cheaper solution existed in the room next door?

These are some of the problems that we looked to solve. And with this, we have some pretty interesting plans on how to save money. I will cover that in my next entry.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

2 Comments 0 References Permalink Tags: value, software_development, application_inventory, cost_savings