The Next Big Shift In the Collaboration Paradigm

Imagine.

Imagine being able to send out a single message to a large group of people to solicit a yes or no answer, or to pick one option out of list of several options – and have that single message track all the responses for you in one quick view.

Imagine being able to hold a debate – and allowing everyone invited to the debate to weigh in with their opinions – within the container of a single message.

Imagine being able to brainstorm a complex issue with a group – bouncing ideas around – sharing drawings and documents – all within a single container – where all ideas are captured for future use or accountability.

Imagine if sitting at your desk, as the lead of a project, being able to lead a group of stakeholders through a needs analysis session – and into project design with your systems architects, engineers, and developers – clearly and concisely – in real time – no matter where they are.

No, I am not talking about a web meetings or video conference calls. This is more permanent. It's completely recorded and available to be played back to show how the events of the collaboration unfolded.

And I am not talking about emails – emails can branch off into different threads and become a monster to understand once the discussion grows in length.

Not instant messaging, or using a document repository or library or journal.

Not any of those means of collaboration that we currently have at our ready avail.

Not any of them … ALL OF THEM.

Confused yet?

Well, please – bare with me as I try to explain. It takes a second to twist your brain in the right way to see what I mean.

I am talking about Google's newest collaboration platform – still in the development stage – but available to a lucky number of us now to figure out what this new tool means.

I am talking about Google Wave.

This is a not necessarily a new paradigm in collaboration. Instead it is the integration of all the components we currently use to collaborate. In real time – or as people come in and participate and then leave.

The Google Wave development team leaders refer to Wave as what email would be if it were being invented for the first time today.

But as powerful as this concept is, it becomes infinitely more powerful – and easier – and slicker – because many of the services available to you to use to collaborate are made available as Google Gadgets – small simple applets that serve a purpose – and help you provide clarity and conciseness to come to a collaborative conclusion about the topic you're collaborating on.

Currently the beta-test Wave platform provides you with about eleven or so gadgets:

A "yes / no / maybe" polling gadget to solicit responses to the posed question from many people.

A polling gadget that lets you pose a list of options for a group to vote on.

A gadget called "Napkin" – like the napkin you use at a bar to draw a quick picture for somebody to illustrate your point.

A gadget to call a website into an i-frame so you can collaborate on the attributes or contents of the website.

A gadget to provide a map – useful for planning events or travel.

And this is just the beginning.

Of course you can attach a document or a picture in the wave – just like you can in email.

But the real potential power – as I see it - is the potential for this list of gadgets to include really powerful – yet simple gadgets. The number in the public domain will grow quickly – as fast as the number of apps you can download and install on your iPhone or Android cell phone.

As well, for the aggressive corporate class that embraces the wave, home grown gadgets built by their in-house IT shop would continue to increase the company's ability to leverage this tool.

And you know it's certain that wave will make itself available on mobile devices like iPhones, and Androids and Blackberries.

You could have a meeting with a group of stakeholders – some who may be riding on a train or waiting in an airport – participating in the collaboration on the video screen of their phone. And it would not be awkward!

This is the next paradigm shift.

And Google's only the first. Others will follow. Others will come along and enhance this model even further.

And the way that we work together will change. Forever.

But wait – there's more.

These collaborations called Waves are not transient. They are not temporary – or at least they don't have to be.

They can be saved. They should be saved. They become very important documentation.

How many times have you come across a legacy process in your business – and wondered "what were they thinking when they made this decision?"

Well, now you won't have to. You can call up the wave – and you can play it back - right to that point where the decision was made – and why.

And that is just so important to know. But rarely ever captured except in the memories of those who participated, and passed down to those that follow later in stories – like how earlier cultures shared legends around the fires at night.

But now you can witness the moment the decision was made.

And who made it.

And understand why.

I am rather excited about Google's Wave project. And I'm being inspired by what I am experiencing during this beta-test process.

Because I really think this will change the way we all work together – and play together – once it catches on.

And it will catch on.

If you want to learn more about Google Wave – check out this fantastic seven minute video on You-Tube.

It will certainly make your eyebrows rise.

Social Networking – Are We Really?

I have invested a lot of time and energy in the recent months in the tools that we commonly refer to as Social Networking.

I have written articles and joined groups on Helium.com.

I have a found a good number of old and recent friends on Facebook.com.

I have a number of professional contacts that I have worked with over the last twenty years on LinkedIn.com.

And recently I even started using Twitter.com. I even have some followers.

And on a day like today, when I have a little time on my hands, I like to go to all these websites and see what's happening.

But do I really get to interact with these people?

Virtually … no.

Have I made any new friends because of it?

Sadly no.

Oh, there is the odd chat session, or I get to look at someone's photo album. Some memories are shared, and some jokes are typed.

But all in all this whole social networking set of applications leaves me feeling unsatisfied. Empty.

It's missing something. Personal contact. A pat on the back. A punch in the arm. The look in someone's eye when you make them laugh, or pay them a compliment, or teach them something, or learn something from them.

The bonding.

Yes, on LinkedIn, my set of 15 connections extends my social network to a group of people numbering over twenty four hundred. But none of those additional twenty four hundred people know my name. Doors will not open up to me because down some long linked line of people who know people who know people. But is that what I am looking for? For doors to open up? For career opportunities to avail themselves to me?

I don't think that's why I am here? I have a career, a good job with a good company. A company I do not plan to leave until I can retire.

So I sit and consider why I am so interested in these social networking internet applications. And the only reason that I have is because I design software applications and systems for a living. I am passionate about what I do. And these new concepts interest me greatly. The thought put into the potential synergies that could arise – and the safeguards put in place and the requirements that must have driven the design of such sites.

Although I still don't see the advantage of Twitter. The usefulness of Twitter so far eludes me. Yet I tweet away.

There have been only a few social networks that I truly find satisfying. They are not virtual, they are real.

The sailing club Darlene and I belonged to, where sailors could sit around in the clubhouse or on each others boats and talk – about life in general, with the commonality that we all love sailing.

The ball teams that I have played on where after a hard fought game we sit together and talk – about like in general with the commonality that we all love playing ball and we are a team.

The offices I have worked in over the course of my professional life, where in moments of calm we gather together and talk – about life in general and the direction our business is going with the commonality of the role that we play together as a team to enhance our business position.

And any time members of my family get together. My family, my in-laws (yes, even my in-laws), my cousins and niece and nephew.

These are the places where friends are made. These are the environments that give us a commonality – that create the bonds that are missing from the virtual social networking sites of the internet. These are the places where we learn to appreciate each other for our unique skills, for our distinct personalities and for our common values, goals and objectives.

The "We are in this together" bond.

We learned this in our youth in the schools we attended, the teams we played on, the clubs we belonged to, the common hopes and aspirations we were just starting to realize.

Yet, here I sit on a beautiful Saturday afternoon, with my kids splashing in the pool, and my lovely wife Darlene out shopping and running around doing the errands that make our home a paradise. I sit here and devote my attention to LinkedIn or Facebook. To Twitter and to the various blogs I both read and write about sports, Information Technology, friends and family.

I sit and contemplate this while my real friends and family are here – with me now – and they will not be forever. Because time brings change to everything. My daughters will grow up and marry and move away. My circle of friends will likely shift to include new faces and lose track of current faces.

My social network is right here in front of me. And it took me forty seven years to build it.

So will I abandon Facebook and LinkedIn and blogging and Twitter?

Well, probably Twitter. But I will keep the rest of them.

But I will try to remember day by day that my real social network is much more valuable than this virtual social network. And should you see me waver in this commitment – please help me by reminding me.

Because I do find these social networking sites very interesting – from an IT perspective. And I do love what I do.

How Does Enterprise Architecture Fit In An Organization?

Enterprise Architecture (EA) is a term that has been used loosely and redefined to meet specific needs of various IT organizations, movements (such as Java and Open Source), and individuals needs.

Recently I saw a debate on the usefulness of EA being debated in a forum I belong and subscribe to. The business executive was frustrated with trying to understand the principles of EA as it has changed in metamorphic ways to suit the needs of specific groups.

I shared my opinion below with this group – each consisting of readers who hold their own perspective, and each with their own turf in business and IT to defend. I will be interested to see the feedback – but I will put my thickest skin on when doing so.

EA – in my humble perspective – is the bridge between the business community and the IT community within an organization. It holds an equal obligation to the business areas of the organization it serves and the IT strategies in place and their future direction.

Some may confuse the role of CIO with that of the highest level of EA in the organization, but most often, the CIO is protective of their IT holdings which degrade their objectivity.

Quite common are environments where the business community must request a service or function be designed or modified. The result of such environments are simply piles of IT solutions with no clear sight on long term IT objectives.

Such environments are frequently plagued by systems that quickly reach the end of their lifespan before fully optimized or integrated with surrounding components to reach their full potential.

On the other end of the spectrum is the IT department that dictates the services to be made available to the business community it serves. The outcomes of such environments usually include very integrated systems that provide services that may or may not be used by the business. These environments are built on state of the art technology not yet mature enough to be fully utilized.

In the middle of that spectrum – a fairly broad band in the middle – lies the environment governed by the principles of EA. EA is an independent objective function. The EA may be the role of a sole individual (a very special individual) or more commonly in the form of a committee – each equal and representing different aspects of the business community and the IT department.

EA balances the immediate and long term objectives of the business to insure both sets of needs are met – while the technologies that service those needs are responsibly deduced to insure the technologies are feasible in terms of security, affordability, scalability, risk, and longevity while at the same time to insure the best chance for ROI to be achieved. Extensive modeling from both business and IT perspectives flash out such strategies giving optimum view to the full 360 degrees of the impact on organization.

An IT environment governed by AE principles may very well still have a core backbone of key independent COBOL batch processes that perform the organizations basic processes while extending the use of the processed data with newer technologies as they are adopted in standardized means to fill specific roles.

There is no one definition for EA – each organization who employs EA principles determines that definition clearly and concisely.

In short, true EA – much like a Zen-like approach to life itself – in an ideal to strive towards, but that few truly ever achieve. But by adopting the EA principles and religiously applying them will only strengthen the organization it serves and governs.

Getting Your People Up To Speed

The most neglected aspect of any IT shop is documentation.

Think about it? If a new person comes on board in your IT department, how long does it take for that person to get up to speed before they can be assigned their first task? I am not just talking about programming and coding, but any aspect?

Walking into a new work environment is daunting to the best IT professional. Most often the learning curve is huge as the newbie tries to digest the various business rules, principles, best practices, and data structures of your systems.

Usually the newbie finds they are sitting at a desk, often without a computer in those first days, and reading binders of photocopied user manuals – screenshots with minimal text written by co-workers. After that they are most likely given stacks of source code to look at with little or no context as to how things are put together.

Even worse is the existing co-worker, who knows System A like the back of their hand, but now has been asked to do some work on System B.

Face it, most IT environments are lax when it comes to documentation. It's an afterthought. Or the documentation has become obsolete as the system evolves and changes to never-ending requests from the users.

Good documentation practices are the key to knowledge transfer. Getting newcomers up-to-speed quickly so they can be as productive as you need them to be. Your department did not go out and hire that new analyst or architect because you knew six months from now they might come in handy? Most likely you need that person now, and you finally received approval for the new hire, or the transfer from a different area.

Good Documentation is the key to a successful transition.

This means that documentation practices must be put into place so that new hires can be productive as quickly as possible. And what IT manager wouldn't like to show their superiors how quickly they can get their staff at full productivity?

In my experience, I have found the following levels of documentation to be the most effective. But I do admit, this is my own preference, and the luxury of such detail may not be affordable to every environment. But I do believe that more is better, and accuracy is the key to success. Here are my top preferences – using the names that I know these documentation structures by, their purposes, and their target audiences both before and after a project is completed:

The Vision Document – Also known as a high level design

This document most often is originally targeted at high level management. The language is non-technical and describes the intention of the newly planned set of components. This document contains the following pieces of information:

Overview – a set of paragraphs that describe the overall purpose of the system.

List of components - a high level statement of each component describing what each component is for , what data is captured, who uses the component and why, and how it interacts with other new or existing components. Simple UML object diagrams are very helpful to the reader as a well drawn yet simple illustration can quickly bring establish the components purpose quickly, with text to describe the picture and add those subtle nuances that a simple picture cannot detail.

Mock ups of the user interface to show the flow of high level events is a great additional feature.

A Realization Document

The Realization document is simply the finished version of the Vision Document after the project has been completed and implemented. Hence forth, as future revisions are made to the components of this system or project, it is the Realization Document that is updated to reflect those changes.

The language should remain at a non-technical level – but now that all the unknowns have been answered, the level of detail can be slightly greater to answer the readers questions before they are asked.

There is one additional piece of information needed in the Realization document:

List of changes – a short list of each change to the system since the vision document with a description of how it changed the component, why the change was necessary, and the benefits the change brought to the overall system.

Mock up pictures of the user interface should always be replaced by actual screen shots of how the user interface really does look now.

The Detailed Design

I like to think of the detailed design as the workbook that the entire team will use as the various components of the system are flushed out and documented. A well structured detailed design document will allow multiple team members to update their specific sections of the document simultaneously, each building off the depth of the other team member.

This document has several audiences:

Managers will use this document to determine the progress being made during the development cycle, or after its completion as a reference to see what components were built in which ways.

Technical Architects will describe the physical components such as network servers, communication aspects, security aspects, and hardware requirements.

System Engineers will describe the various components of a system, subsystem, or subset or groupling of components. They will use this document to describe the break down of the components to the object the level, and the relationship of the objects to each other and how they interface with each other. The business rules to be addressed by the system are detailed and assigned to each object and their role in enforcing each rule. These rules are the direct map back to the system requirements either gathered by or given to the engineer by a business analyst. As well, this document should contain a high level view of the items to be included in test cases – for both system and end user testing.

Software Designers will use this document to break the described objects down into classes, and to translate the fulfillment of those rules into logical algorithms – most often using pseudo code or examples of existing logic. The software designer will also pinpoint where common or reusable pieces of logic should be either created or employed from existing packages.

Database Analysts (DBAs) will use this document to assist both the Software Designer and the Software Developer in optimizing the structures of tables, focusing on primary key, data integrity, referential integrity, naming convention and normalization or de-normalization strategies.

The software developers will use this document to extend the software design into actual source code, documenting which source code pieces are used to fulfill the design, maping the memory objects to the database table columns, working out stretegies to achieve complicated objectives, such as node to node timeout mechanisms, edit check validations, and even image resources used to decorate the interface.

At the same time, all the above persons will maintain a section at the back of the document to track known issues, resolutions to issues, and general notes of things to look out for – such as features of third party components like ODBC or JDBC drivers , COM, CORBA, or included package items.

Each author of this document should use diagrams and models to help the other members better understand the nature of relationships and attributes of the various aspects they are describing.

My preference has for the last several years been UML (Unified Modeling Language) 2.0. My reason being that in my own experience, the sets of diagrams – from use case diagrams to assist in requirement gathering exercises to physical, and logical views allow team members to create a 360 degree model of the solution.

The benefit of such a document written in this manner is that it keeps everyone in the loop as to all aspects of the project – that component of the project of which they are mutually responsible. There have been many examples in my own experience where this technique combined with comprehensive UML modeling has caught development issues very early to be dealt with before they become oversights- costly oversights that might spell the failure of the total project.

After the initial document has been completed, just prior to the implementation of the new system, subsystem, or components / modules of the system, these document should be signed off by all stakeholders. In truth there are several sign off points – when reviewing at various stages to provide status to all parties concerned.

As with the Vision document, this document will be your source of information for future maintenance or enhancements to these components. And those changes must be tracked in this document, or else the document quickly becomes obsolete.

The end result

The result of this documentation is a comprehensive set of reference that should be easily understood at various levels of the development team, management team, departmental executives, and executive.

These documents should be stored electronically in a central repository – easily accessible to all concerned parties. More elaborate libraries – such as SharePoint Repositories, Lotus Notes Document Databases, or even version control tools like CVS should maintain version integrity of the documents and be easily searched for by any one looking for them by simple key word searches. To simply shove these documents into a shared network drive organized loosely by folders will greatly diminish the impact these documents will have on knowledge transfer and managements desire to even attaempt to look for the information will be eroded to the point of non-existance.

The Big But …

"That all sounds wonderful, Fred – but our system is a decade old now? Should we document what we already have?"

All departments no matter how busy do have points of time where team resources are idle. Assigning existing components to be documented during such downtime – by the subject matter experts – is not a wasted effort. Every system has a life cycle. At some point that system will come up for maintenance work or be replaced by a new system. At some point there will come a time in the future where such doicumentation will be seen as invaluable, and the genius who showed the foresight to action this task will be seen as a strategic leader with pro-active vision.

And who doesn't want to be seen in such light by those who decide your future.

The Pendulum Swings

I think there are few industries – if any – that change their minds as fast as the IT industry.

I like to use the analogy of a pendulum to discuss this topic. Because at a high level, the decisions go back and forth, swinging right to left. And the one certain fact of a pendulum that you can count on is it will only swing so far to the right, stop, and swing back again to the left.

In this analogy, you can count on the fact that what is old will soon be new again.

Take the example of the mainframe computer.

For awhile – in the early years – it was the only game in town. The only device you could hook up to the first ones were card punch readers to act as your input, and a printers to act as your output.

Then the terminal came along. It had a keyboard that users could type their instructions into, and see the output on a monitor.

At the end of this great pendulum swing – the first swing – all data was centrally stored in one location with no redundancy of data in multiple places.

Then the personal computers started emerging. And the first applications available were word processing programs, spreadsheets, and database managers.

But the data the users of the PCs wanted was stored in the mainframe. A would user call the computer room, and request a report from the mainframe. The computer guys, after a little hassle, would send the PC user a printed report. The printed report was then typed into the PC – into a spreadsheet or database by the PC user.

The result? Redundant data resided in the corporation – all over the place. Every PC that contained a list of customers, products, sales forecasts or results had a different set that was updated only on that PC.

The PC – after a slight civil war between data processing department and every other department in the company – sparked the invention of the 'terminal emulation card' – which required cabling to be run throughout a building, poking out the walls of each office that had a PC, and plugging into the card that had been inserted in the PC.

The result? The mainframe was still a separate and independent data system. The PC user would have to switch their computer from PC mode to Terminal mode. There was still no bridge to get the data from the mainframe to the PC. But as these cards were evolving new features were added to allow the output from a mainframe batch process to be used by a PC. But the work for the PC user was still tedious.

And the data redundancy problem was getting worse – not better.

By the way this same era also introduce the popularity of the computer consultant, a supposedly skilled individual who claimed they could automate the tedious aspects for the PC user – but that is fodder for a later discussion.

This is the end of the first swing back - to a collection of desparate systems each holding unique resources.

Terminal cards evolved to become network cards and the Local Area Network was born. At first the LAN was used to allow multiple persons to share a common device, like a printer. And the mainframe was still a separate sacred entity.

But then network servers started to appear. PC's that had no user – but acted mostly as a central storage site for documents, spreadsheets, and PC databases.

The redundancy issue was reduced, but not eliminated. There were still no direct ties to the mainframe. So the term "data source of record" became popular to describe the elite status of the mainframe data content.

The pendulum was now in midway swing back to the central data repository state.

The company was now littered with two levels of program applications – those that ran on the Mainframe – and those that ran on the local PC's – and eventually across the LAN.

The ground was now set for the most daring venture of all. The ability to allow PC based applications to access the data on mainframe using various client (PC) to server (Host) data transfer methods – among them ODBC. Now the logic could reside on the PC – and the data was retrieved from the mainframe, to the PC – processed by the logic on the PC – and written back to the database on the mainframe.

The result? Much better access to the data by the company – and the distribution of responsibilities to maintain that data. But the problem was that the logic on the PC was often flawed and the integrity of the data on the mainframe was compromised.

This marks the end of the pendulum swing of the data processing department – and the birth of the Information systems department.

As time and technologies progressed – and the logic of programs running on PC's consistently tweaked – now by the IS department – the data integrity issues started to wane.

But then we saw the birth of the Internet. And the internet allowed people to share data in completely different ways. In fact more than data was being shared. Communications became an integral part of the company's Information Systems as email exploded.

But the most influential aspect of this paradigm shift was that it was now better understood how to have the logic of a program reside on the host server and downloaded to the PC every time it was to be run. And one central source for code.

And the pendulum had swung all the way back to a single central repository of logic and data.

But such a function was a bit to much processing to take place on the single host – it could not be expected to respond quickly to requests for data and for logic. So the two responsibilities were split across two different hosts.

But with the adoption of TCP/IP taking over corporate LANs, security became an issue. Anybody on the outside could get in, view and steal sensitive information, and even maliciously harm the system. So a new level of host was invented. The security server would sit independently of all other resources and act as a sentry to keep out all but the authorized network requests.

So the pendulum now is in mid-swing back to disparate systems – and again facing data rundundancy problems – albeit much smaller than the first swing back.

By this time, the IS department had grown significantly to support all these various services – from server administration, software development, PC application support and development, and training. In most circumstances, the IS department now employed more staff than any other departments.

Think about this.

Let's say your company makes widgets. You sell widgets. You fix widgets. You ship and receive. You do accounting. You do research and development to make better widgets.

Each of your departments at Widgets Inc. has totally different needs – and a few common needs. So each of those departments have totally different – yet urgent needs for their set of information system components. The IS department has now grown to support all those needs. And as technology changes so fast, much more time is spent training IT staff on new technologies than any other part of your business.

Because information systems give the widget company the potential to make better widgets and reach newer markets. Quite frankly – and perhaps generally – you can judge the success of the IS department by the success of the company.

So the key to optimal business success is to make your IS resources as efficient as possible.

So what does this pendulum swing allow us to forcast?

1. You can only allow your IS staff to grow so large.
   
2. This means the amount of effort to maintain so many disparate – yet tightly integrated systems must be eased.
   
3. This means that simpler systems for security, server administration, database management, and source code logic must become more prevelant and usable.
   
4. This means that IS staff can now manage more technologies easier.
   
5. This means a shift back to the central repository of services is inevitable.
   

It will be interesting to see as we move forward how things will progress. It will be interesting to see how corporations like Microsoft – so dependent on the disparate systems model – will fare as other company's like Google move us closer to the central repository model.

By the way, is there a school left in the world that still teaches COBOL?

Incompetence Rises

Over the last thirty years of my working life, I have been continually amazed at how many times a person who fails or does poorly on a project or large task usually gets promoted to manage the outcome of their failure.

It happens time and time again.

The Peter Principle states that “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence“. In some cases though, The Dilbert Principle is more a appropriate scenario - where success occurs despite the earliest signs of incomepetence.

Such a scenario basically unfolds where there are limited resources to assign to a task of some visibility and importance. The management at the time has no option but to assign the task someone not who is either not properly trained, lacks a deep understanding of the task, or is simply incapable.

The projects of the task always run far beyond the projected timeline, and tremendously over budget. The planning that should have been put into the task at the beginning was either not performed, based on false assumptions, or was completely misleading in the result.

As the project progresses, sympathies increase for this person performing or leading the task. Their visibility increases as they are always the orator on the issues at hand – and as time progresses, they are seen to be the subject matter expert on the task.

At some time, the project completes. Everybody takes a deep sigh of relief, only to find shortly thereafter that the problems cascading from the result of the task now involve more and more persons to deal with them. More firefighters, if you will.

So this incompetent oaf who started the project, took it down the misguided roads to ruin, has actually made a positive name for themselves by the sheer genius of their incompetence.

As a result, they get promoted to manage the fiasco. And most of the time they do so lovingly and passionately. They do so in a defensive – reactive mindset. Suggestions made to fix the outstanding problems are often rebutted by the new manager by such phrases as “trust me, you don’t want to go there” , “that’s how we have always done it”, or “the problem is just too complicated for you to understand”.

Often times the succession of this person up the corporate ladder does not end there. They remain visible as a tough person who has fought battles and understands the underlying issues.

This is only one example of the Dibert extension of the Peter Principle in motion.

And this, my friend, is one way in which incompetence rises to the top of the heap.

The Main Three IT Professional Environments

Every IT shop I have ever seen is different.

The roles are different, as the purpose of IT in every environment is unique.

When I discuss this topic with people, I am always quick to point out that there are three main categories of environments that every shop falls under:

• The software development company
  
• The IT department in a company or corporate environment.
  
• The IT consulting firm

The software development company

The software development company has a set of products that they have develope, packaged, and sell on the market. Their focus is to increase their market share of their niche consumer.

Their new products and enhancements to existing products are driven by the market, and their perception of what their target market want.

Creativity is encouraged in this environment and products are quite often put into the marketplace sooner to be the first to draw attention to their short-lived status of being “unique“.

The IT department in a company or corporate environment

The IT department in a company or corporate environment is more concerned with keeping the systems of the company up and working, and enhancing their systems where advantageous.

Quite often creativity is stifled as the concern is to get a project completed to meet the end user requirements. This environment is often caught with aging legacy systems with complicated hooks into new functions.

The consulting firm

The consulting firm, more often than not, is a hybrid of the software development company and the IT department of a company or corporation. Relationships with customers are most often short lived. But there are usually marketplace products developed and sold. Their approach is usually to sell a product to company or corporation, and leverage the implementation of that product in terms of customization, support, and extending their presence by performing needs analysis for potential projects the company or corporation may feel their own IT department is under-qualified to tackle.

I have worked in all three of these environments. All three have their benefits. All three have their drawbacks.
The roles of the employees in all three of these environments are as different to support the different purposes of each environment.

The ebb and flow of each of these three environments

The software development company environment is most often a pro-active one.

The software development company is usually driven by a marketing team who perform needs analysis .

They meet with a product manager to describe their concepts. The product manager uses those on their team to design a prototype to present to the marketing team and gain feedback and hopefully sign-off or commitment to proceed. From there the development team builds, tests, and continues to present to and get feedback from the marketing team. The finished product is test marketed, and if successful – put to market lead by the marketing team’s campaign.

Once on the market, the product manager in conjunction with the marketing team monitor the success and feedback of the product to determine a long term strategy for enhancements, support, and direction.

The IT department of a company or corporation’s environment is most often a reactive – although the corporate culture of the environment may be a pro-active one.

The IT department usually has two functions – to respond to the requests of company departments – within the constraints of that department’s budgets – for new software tools to perform tasks currently performed manually, or not satisfied by their existing tools.

The hierarchy of responsibilities is much deeper than that of either a development shop or a consulting firm. The CIO (Chief Information Officer) is usually a vice president level position, followed by various levels of managers depending on the size of the company and the breadth of the IT department.

Needs are supplied to the IT department by the business analysts of the requesting departments and supplied to the architects. The architects then blue-print a solution.

Components of the blue-print are then distributed to various teams, lead by a manager, systems engineer, or systems analyst who define the exact scope of their assigned components. Each sub-component is then designed and specked out.

The analysts and architects of these components meet frequently to review their specifications to ensure these components will fit together. The software developer is then let loose to write the code to meet the specifications – and nothing more than the specifications. The finished code is tested by both the developer and usually a person dedicated to the role of testing. Throughout the process, the various components are tested together to ensure cohesion of the overall system. Once testing is complete, the project as a whole is implemented in a staging environment to be tested by the future users of the system. When signoff is achieved by the users, the project is implemented and the system is put into production.

On the other side of the curtain, a team responds to problems the users of a system are experiencing. Problems are recorded, prioritized and fixed by either finding and resolving the bug in the system, or setting the data used by the system to a proper state so the system can resume operation. The cycle for such fixed is much shorter, with less testing. The priorities are based on the criticality of the system and the urgency for correction. This environment can be extremely stressful and wearing on the staff.

The consulting firm is usually a much looser organization than either the software development company or the IT departments of companies and corporations. This environment is very proactive and is geared towards establishing relationships with the customers which they hope they can translate into trust. Once the relationship exists, the consultant will search out flaws in both the customers process and systems, and ensure the customer that their solution will be inexpensive and effective.

But this perceived approach usually contradicts their intention of extending the duration of the relationship, exceeding time lines and budgets. The objective – truly and not facetiously – is to do as little as possible for as much as possible. In most cases there is no long term commitment to support the result.

Your experience with these groups may be different than mine. You may even identify more categories of environments than I have here.

Let us know what you think, what your experiences have been, and even your preferences or your opinions on each.

Let’s start ProjecTalking.

Welcome to ProjecTalk

There is more to having a successful IT team than simply knowing how to write source code.

Yet as I surf the Internet, the vast majority of discussion is how to write rock solid code using various techniques, technologies, and best practices.

But techniques, technologies and best practices are not constrained only to source code development. There are so many more roles in today’s IT environment, and it is my hope that we can use this space to discuss the fundamentals and intricacies of such work areas as:

• Systems Architecture and the project identification process
• Needs analysis and requirement gathering
• Project scope control
• Analysis and design
• Integration, user, and post-implementation testing
• Customer expectation management
• Communication progress and status to project stakeholders
  

In short, we will focus on everything but the actual practice of writing code.

Over the last 20 plus years, I have held positions up and down the IT role ladder. So I will be sharing my thoughts and experiences. But I do not intend to simply tell you what I think.

Instead I am hoping I can inspire conversation and debate as we discuss these topics … but in a way uncommon to most IT environments – as calm, rational, professionals.

There are several blog sites I follow religiously – one sports blog in particular. And the lesson I have learned from observing these sites is that the while the authors of these blogs are knowledgeable in their writing, the real insight comes more often than not in the discussions and debates.

I will certainly do my best to keep the topics frequent, relevant, and my own insights as clear and concise as possible. I am also hoping that those of you that wish to participate as authors will send me a note.

I look forward to this new adventure. And I am really excited to meet those of you out there who share the same interest, and learn from your experiences and opinions.

As the same time, I will continue writing my essay’s on my original Head Stuffing site. Those stories, after all, is truly what I love to write.