Midwest IT Survival

Organization Silos Impeding your Enterprise Architecture?

There are countless sources extolling the benefits of a strong enterprise architecture strategy. The experts all agree on an effective enterprise architecture and even more so the larger the organization’s consumption of IT services. But recently, I’ve been reminded that the IT organizational structure, especially the structure aligned to providing new projects and new technical solutions has a dramatic impact on the ability for an organization to realize the benefits of established enterprise architecture.

In short, the more the IT new project and solution delivery organization is directly aligned with the individual business unit or group it supports, the more likely a spaghetti architecture will be the result. To help outline this point, below is a quick graphic of a sample organization chart that shows the two extremes:

Extreme A = Business group/unit functionally aligned:

Extreme B = Common function/service aligned:

The “extreme A” example is functioning with each vertical group acting as silo. Each silo is held accountable for delivering solutions to their business unit. In turn, each business unit will drive their IT silo to meet their needs exclusively. There is no inherent need to collaborate with their peers supporting other business units even if there are “enterprise architecture goals”. In my observation, collaboration might actually be viewed as a distraction to getting work done. There is essentially no organizational driver to force standard solutions and re-use of technology assets.

Sure, an architect in one group might have a strong personal relationship with an architect in another group, but unless they are trying to share ideas that happen to be at relatively the same level of “maturity” for each silo’s needs, they will unlikely be able to produce a common, re-useable technology used across both silos. Architect A attempts to work out a common solution with Architect B but suddenly Architect B’s project gets accelerated. Suddenly Architect B has to quick assemble a slimmed down solution that can’t be dependent on Architect A’s requirements or time-line. And sure, everyone might meet and agree to “retrofit” Architect B’s project with a more standardized solution with Architect A’s project in a later phase/iteration, but it would take an amazing level of cross-silo organizational governance to make sure that happens. If that standardization would in any way delay Architect A’s silo from delivering from the business, the standardization most likely gets pushed far and far out until no one remembers or even exists that remembers why the architecture alignment was needed in the first place.

Other potentially non-technology specific negative byproducts can evolve from this structure:

• Strong versus weak silos

One silo maybe more effective at deploying more current technology by the very nature of the business unit’s needs. As an example, consider a customer product or engineer unit compared to say, finance or one that uses in-house developed technology versus another with outsourced/SaaS technology. This creates a problem of talented architects and developers/others actively seek out roles within the perceived “strong silo” creating an even stronger silo compared to the other silos.

• Overall increased IT cost of ownership

As each silo is standing up technology to meet the business unit’s needs, they are all solving basically a significant number of the same problems with different solutions. Those solutions come with reoccurring maintenance, product end of life and all the traditional support and vendor management overheard. (I’ve written extensively about vendor management in past articles.) Then, to drive up costs even further, as some business need to see a “single view of the customer” or some other cross silo business challenge pops up, the cost to map all the data across the disparate systems is exceedingly high. In addition, not only does the mapping need to occur, but the technical (and probably some business) workflow needs to be altered to continue to keep all the data in sync. Someone suggests we need “Master Data Management” and now you have the cost and complexity of implementing a system to manage the data across all your systems.

The “extreme B” example brings the solution needs from each separate business unit/group into a common functionally aligned project delivery discipline. The goal is to leverage best practices/success stories from working with one business unit/group across to the other business units/groups via the common management structure by discipline. More specifically, the goals and objectives of each IT service discipline or function can be aligned to efficiencies and re-use within the specific discipline. Project Managers ensure they have common mechanisms to track and report on the project process. Business Analysts make sure they have a common framework for capturing requirements. Architects, develop unique frameworks for common requirements across all projects. Developers follow a consistent coding standard and reuse objects for data access, error reporting, and instrumentation, etc. The same goes for the other disciplines. Each discipline can focus on efficiencies aligned within their area of responsibility. And since each discipline has a somewhat singular work input and output for all business units, there is complete enterprise visibility to what is needed per each discipline. Thus, ultimately, the architecture team is looking across the entire enterprise at all the requirements and multi-year plans and can be charged with common frameworks for essential IT needs:

• Authentication
• Authorization
• Entitlement Management
• Business Rules/Workflow Management
• Business Event Management
• Reporting
• Data Structure, Storage, Management, Retention, Archiving
• Auditing and Compliance
• Capacity Planning
• Disaster Recovery

… and probably a bunch more that don’t immediately come to mind!

In conclusion, a strong enterprise architecture strategy gets a significant boost from a discipline aligned organizational structure rather than a business unit/group aligned structure.

Anyone have any thoughts to support and/or contradict my thoughts here?

What do I work on now?

Have you ever stepped back and observed a [maybe yours?] MidWestern IT technical team and wondered why all the engineers seem legitimately busy, yet there doesn’t appear to be a proportional amount of production (or test, or QA) project changes and/or deployments?  Phones are ringing, emails are being sent, multiple instant message chat session windows are open, requirements and design documents are being revised and shared but environment changes aren’t being implemented.  Sure, your organization maybe large enough that duration from project kick-off till the first production deployment could be over a year and a half or more.  In a past life, I was responsible for a web customer product wide single sign-on system that once we completed a system upgrade of some sort, we had to immediately kick off a project to begin the next upgrade because the software and OS refresh cycles were averaging 1.5 years from start to finish.  Yet, have you ever considered that your resources might be getting thrashed with too many concurrent requests from too many sources without any easy mechanism to determine what to work on first, next and what can be put on hold?

I consider team member resource thrashing to be equivalent to an application server that is being overwhelmed with requests from many clients (such as web servers in a web tier).  If you have ever observed high volume systems, such as heavily used Internet web applications, there is a threshold of total requests at which the system can no longer service all the requests and disasters occur.  As the client request count rapidly approaches this threshold, the application servers continue to spin up more threads to assign to each request.  The closer to this threshold, the more CPU cycles are expended in starting, pausing and managing the threads themselves and not the work the threads need to do to actually complete the original work request itself.  The thread count climbs, the CPU cycles to manage that thread count climb and the whole system eventually falls over and the tough job of recovery under extreme load begins.

This thread thrashing is analogous to team resource thrashing.  There clearly is work for the team to be doing, but so many disparate requests are coming into the resources on the team that every team member is barely able to get someone off the phone with one request before an email arrives with additional requests.

Now, I can’t take full credit for this succinctly brilliant assessment of a common large corporate IT occurrence.  In a past professional life, my wise senior manager was astute enough to identify this depiction during a production issue.  The enterprise service my team was troubleshooting was causing performance issues across a number of highly visible customer web applications.  Many teams were demanding status, asking random technical questions and posing endless theories of the few resources on my team as to why the systems were behaving as they were.  We could barely get any real technical analysis completed as we had to appease this growing horde of interested bystanders otherwise risk being cast negatively as “non-partnering”.  The resource thrashing assessment as a barrier to what they ultimately wanted: answers caused the external groups to take some pause.  This allowed us to dig in, really figure out what is wrong and fix it.

I’ve written a series of articles on making it a priority to establish a single view of the work for you team in order to be able to do effective resource planning.  But in the process of determining the single view, also count up how many different work request sources exist.  You may be surprised to find in excess of eight, nine, ten or more ways work can be requested of a single resource.

So what is the big deal?  If someone is getting ten different sources of requests for work, how does that someone figure out what to work on and what can wait?  Most likely, the “squeaky wheel gets the most grease” adage takes over.  Additionally, many project failure assessments find that excessive multitasking can cause key deliverables to missed or delivered below quality.  (Third most frequent cause of IT project failure in a survey by Steve McConnell with construx.com)

What can you do to improve this situation?

Draw a picture

One of the first things you may want to seriously consider doing is to sit down with the individuals on your team and draw up a picture of all the work request sources.  Peer management maybe generally aware that this resource thrashing is going on, but present them with a picture of just how many sources and it makes a bigger impact.  By making the problem more visual, it sets the tone for why external groups requesting work aren’t getting the expedient service they are expecting.

Identify prioritization mechanisms

Another thing you can do is identify the most critical groups and start a dialog to establish a means of prioritizing work requests.  Is it the project management office that is feeling the most pain from not having a predictable resource model nor consistently met delivery timelines?  Get your single view of the work in front of them and the companion back log of requests and get them to help prioritize.  Setup a re-occurring meeting to bring revised views of the work requests for consistent re-prioritization and the winds of “this is hotter than any other project” blow regularly.  Is it direct product managers or business stakeholders that have to work directly with IT that are frustrated?  Do the same thing as with a project management office, just be prepared to have to cautiously identify other business groups that are claiming higher priority and be prepared for some grandstanding or other self importance postulating as the business groups with the most impact on the bottom eventually rise to the top of your list.

I would like to re-stress, it may seem like a lot of data gathering and schedule building, but I’ve never seen this type of team resource thrashing challenge get solved by any magic external group or process.  As an IT manager, you may have to roll up your sleeves and did into the scheduling data.  Finally, this isn’t a “fire and forget” exercise.  Be prepared for having to repeat this data true-up on a regular basis to continue to establish a more clear prioritized path forward.

Anyone have any other tips on how to get in front of a team of thrashed resources?

Abruptly in the job market, what to do?

Expansion and contraction of the IT labor force in MidWestern companies is nothing unusual. In America’s boom and bust capitalist economic system of recent decades, during booms, MidWestern companies expand their IT labor force in order to capitalize on automation efficiencies and work volume management through IT enablement. When the boom time is replaced with a bust or significant drop in demand for a company’s products or services, the need for IT automation, overhead spend, etc. follows suit. As some may know, I was recently unemployed. Due to the terms associated with leaving my previous employer, I am unable to share any further details.

Finding myself somewhat abruptly in the job market, I now had to make some choices. There are a number of Internet resources suggesting this new loss of employment state is a great opportunity to re-assess your life priorities and career path. Others have mountains of compelling evidence to jump right back in the job hunt before goofing off becomes your new employment default (such as “Nine Reasons Not To Delay Your Job Hunt” or “Clearview Counterpoint: Should Employees Downgrade Job & Salary Expectations For Next Few Years?”). For me, I had contiguous employment from 1991 through mid-2001 (victim of the dot-com IT employment burst, anyone remember the birth of Odd Todd and Laid Off Land?), then late-2001 till May 2010 (now victim of the Great Recession). Thus, for me, I had the benefit of going through this experience once before (although it seems a lifetime ago as I write this) that offered some guidance on what works and what doesn’t work for me when faced with unplanned unemployment. I thought I would share some of my experiences with shifting from the work routine and the familiar office scene to having that routine completely shut off.

Realization = Loss of Structure

Your proverbial 9 to 5 structure is suddenly replaced by a giant void. Nothing really forces you to get up early and jump into the shower. Yet if you are at all like me, you are pre-programmed to do so. Thus, you find yourself compelled to do it anyway. For some, this maybe a gift from the gods, but for folks like me who have had almost 20 years of 9 to 5 familiar work driven structure, it is a striking realization. The realization is that there is no compelling reason to get up and be productive because there is no demanding employer out there. This realization can indeed be a bit shocking.

Opportunity = Replace Old Structure with New Structure: The Schedule

I’ve found that creating a new structure worked for me. I got up relatively at the same time as when I was going to work. I completed the same morning routine. I did choose slightly more casual clothes than I normally would wear to work as a minor benefit. I then grabbed my really old, clunky laptop, jumped in the car and headed to “the office”. This familiarity of schedule helped me to keep focused on the future rather than dwell on the present or the past. I was used to getting to the office and jumping right into the work. Now, I just replaced the previous work with the new work of finding a new job.

Opportunity = Replace Old Structure with New Structure: “The Office”

I replaced “the office” with local coffee shops. And since I was planning on working, not catching up with an old buddy, I sought out coffee shops that met the following criteria (pretty much in the order of priority):

• Free (reliable) wireless Internet
• Tables for setting up a work space (not just chairs for lounging)
• Power outlets in easy reach
• Free coffee refills
• Enough noise so that it re-creates your office environment but not so much noise that you can’t focus

I also found having a few different destinations instead of just one helped break up the monotony.

I was surprised by the number of other people with laptops, notebooks, papers and cell phones buzzing around me that helped create that familiar office like environment. I tried local libraries which always offered free Internet and good desk setups, but the quiet was too non-office-like for me.

Realization = No Coworker Interaction

Every IT job imaginable that involves traipsing into an office comes with some degree of coworker banter. In addition, most if not all MidWestern IT jobs come with business/customer/client/management interaction. Once you are unemployed, that interaction ceases to exist. It is always amazing to me how much that professional and social interaction becomes an integral part of your work life. You might not realize how much a part until it is suddenly non-existent.

Opportunity = No Coworker Interaction: Replace with Social Networking

Remember all that career advice to build a professional network of people for times such as these? Now is the time to get some of the payback for your efforts in keeping in touch with people for which you crossed professional paths. You name the social media channel and I announced my availability in the job market. From Linked-In to Facebook to Twitter to even my personal web blog, I let everyone know I was back in the local job market. I also pulled out my list of professional email addresses collected over the recent years and sent everyone a brief personal note indicating my change in employment status and a brief indication of what type of work I was capable of doing. I chose the word “capable” strategically to cast the widest possible net of job options. Sure, I might not want to do X, but rather Y. Yet, if I could successfully do X and there is an opportunity to do X in the near term, why not engage in some hopeful dialog? You never know when a conversation about doing one thing can lead to something more to your preference. In my opinion, when looking for work, having as many proverbial doors open is best.

Results = Surprising

I was completely amazed by the number and immediacy of the responses from all the media channels. Almost instantly, people were responding with understanding and support. I also received a number of direct phone calls to chat about possible opportunities. There was even someone I last interacted with in grade school that volunteered to get my resume in front of a local software company’s head of HR due to his relationship with the HR head from his past.

I continued to share my updates via my social media sites. I didn’t post every five minute statuses “… I just posted to ABC Company, got umpteenth cup of coffee, now headed to the rest room…”, but I focused on periodic upbeat, positive news in reaction to my search progress. Again, the response was equally positive and upbeat. This contributed to maintaining some level of familiar coworker banter to keep oneself positive about future prospects.

Lastly, I’ve heard of people recently losing their jobs and then hiding the job loss from friends and even family. Being my second time around in the forced unemployed state, I completely looked past the possible shame, embarrassment and sense of loss and immediately refocused on letting the world know I have value to bring to a new employer. Also, more than 1 in 10 people are currently unemployed thus it is far from a shameful or embarrassed state to be in. Thus, the more people who know you are looking for a job, the more chances someone will know someone who needs the value you can provide.

Summary

Hopefully some of my experiences captured above will help spark others in the throes of finding employment in the Great Recession. There are probably a whole slew of other tidbits but these were the ones that jumped out at me initially:

• Consider a job search schedule that somewhat matches your recent work schedule.
• Reach out to everyone via every media channel you can image and let them know you are looking for a job and what you are capable of doing.
• Share your successes via those media channels in a reserved but on a frequent basis .

Anyone have any other tips to share?