Do you have the right skills to speak the right speak and do the right things?

Are you really ready to work in a large company?

Recently I've had the opportunity to speak with some college graduates and ask them about different aspects of their work and college-level experiences. They were taught theory and some practical skills very well but they lacked the right focus to help them be successful in a company setting. Book knowledge and practical implementation cannot be two separate things.

They lacked the tools to be successful as a developer within a team!

This is not an analysis on their interpersonal or communication skills. It is merely an observation on the understanding of what is required at a large company.

Teams work together. That means sharing thoughts, sharing server space, and sharing code. There are concepts (and tools) in place to help make this work easier, such as:

• Source Code Control

• Collaboration Areas

• Bug/Defect Tracking

• Change Management

• Code Testing and Tools

• Code Migration

• Enterprise Standards

• Naming Standards

• Architecture Compliance

• Change Control Boards (and approval)

Additionally, there are newer approaches for development, rapidly being adopted at large companies. This enhances the standard software development life cycle (SDLC) with items such as:

• Agile Development

• Test Driven Development

• Self Documentation

Some additional areas I noticed lacking were in the practical knowledge space of helping any developer get their job done:

• Requirements gathering and documentation

• Dealing with difficult people

• Problem resolution

Your language may be slightly different, however, most companies have some aspect of these, in order to keep them moving forward, with less complexity, and a higher level of integration.

What I recommend you do:

• Read blogs (find some software development blogs and follow them)

• Read books (outside of school, on different topics)

• Get involved (in some open-source/community development task)

• Code as a hobby

• Look at the above topics and do some independent research

As someone looking for a job are you prepared to answer questions about these approaches and tools? Are you really ready to work in a large company?

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?.

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.

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.

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.

For decades there had been a simple model in place when it came to consuming software within large companies. It had only two branches, one involved creating something new while the other installation and configuration. Simply stated: "Make versus Buy."

Make decisions involved the custom development of an application to fill the requirements of the consumers. This means that the

software development tools, development resources as well as migration, testing and hosting capabilities all had to be maintained internally.

Buy decisions analyze the funcationality versus consumer requirements as well as the costs of purchasing, licensing, supporting and the installation, migration, testing and hosting capabilities necessary. Additionally the company providing the product is considered. They are usually a company who specializes in a product or product grouping and can deliver it

at a lower cost than what it would take to build it internally. Oftentimes they can also provide the upgrades and support at a cheaper cost assuming the product meets all your needs out of the box.

As the applicaiton portfolios of companies became larger, analysis began to include another branch. Instead of building something new or buying a product to install, you would expand upon the capabilities of an existing tool through merging and/or simply enhancement. This means our simply model is now: "Make versus Buy versus Enhance."

Enhance (or merge) decisions brought together the consumers of the current application and those wishing to have additional funcationality. The amount of regressive testing would increase andt the overall architecture of the application had to be considered to prevent the creation of a Frankenstein application; not adhering to your internal guidelines.

Much of what I read today seems to be leaning towards a trend in large companies to consume software produced and hosted by someone else. You would think this is the "Buy" branch discussed above, however, the method for both consumption and installation is different. This increases our decision tree to now include "Make versus Buy versus Enhance versus Rent."

Rent is a paradigm shift from conventional close-to-chest business practices most companies have used in order to keep competition at bay. Now imagine a time when all you do is start your computer and load a web browser. Inside the browser you have access to all document creation and management, business tools, messaging and any other functionality you need to perform your job. Tthe difference here is that none of these applications are inside your company and you only pay as you use.

So where does this leave us as software developers? Are our days numbered?

I think not -- yet. The movement to a rent-based consumption model takes time. Time for the company to get over their fears or releasing some control to someone else. The problem is and what most people do not realize is that we do it daily. Think about the electricity that runs your factories and offices and ask yourself where that comes from. Do you create it yourself or do you consume

it as a utility in a renting fashion?

For a while software developers will be performing the following:

1. Building what does not exist

2. Enhancing

3. Merging

4. Configuring

We eventually will be doing less and less coding and more and more configuring. As the industry providing us software (and the infrastructure) matures and the reliability increases you will see a switch.

It will take time. Time to settle concerns, time to change opinions and time to move over data and consumers.

I imagine that this switch will allow those companies to focus more on their key products and less on the outlying functionality necessary to run the business.

What are your thoughts?