Innovation, the Business, and Information Technology:

Why the Business and IT Fail

Written By: John Glasgow 6/26/2021

I have spent almost 15 years doing Information Technology (IT) work in Higher Education.  Based on this experience and some years of not working in Higher Ed, I have noticed some themes that hold organizations from being innovative.  The Information Technology department and the rest of the organization see each other as distinctly different. 

People within both IT and the organization view themselves as separate and distinct entities within the larger organization.  This separation results in the misalignment of resources, culture, and strategy.  Without a firm degree of understanding of the enterprise by executive management and mid-level management, neither side will correctly prioritize goals.

Goals? Misalignment of Culture?

You are probably saying, what does this have to do with innovation? What does culture and prioritization of goals have to do with coming up with the next thing that will allow my business to thrive? Everything.

Innovation takes time, creativity, and collaboration.  Without these things, be prepared for just “keeping the lights on.” Innovation does not come when you spend 50+ hours a week working on trying to meet deadlines. Nor does it happen without collaboration.  As far as creativity goes, I do not know many people who have their best ideas when struggling to meet deadlines.

People in Information Technology often work well over 40 hours per week and are expected to be on call 24×7. People outside of IT might decide to purchase a product without consulting IT to determine when and how the system can be implemented.  The department manager then discovers that they need help from IT and pull them in to get the project across the finish line.  The problem is that this is now an emergency for them. People in IT then have to reprioritize everything to put out the fire that someone delivered to their doorstep.

Conversely, people in the business are hurrying to meet quotas, striving to exceed the metrics they are held to continually. They are trying to get their job done and since they interact with customers or the value chain, everything in the business needs to work how they need it to.  Unfortunately, those people in IT are constantly setting up roadblocks, preventing us from making the numbers.

Does any of this sound familiar? The fact is that the two should be one.  Culture needs to change to see them both as the same.  The merging of the two requires commitment from both sides; they need to display unity when creating and finishing projects visibly. 

High-level overview of Enterprise Architecture

The diagram above underlines the importance of unifying the culture between IT and the Organization. Everything the business does is dependent on data, which is presented through applications, which are all kept running by IT.  For more information on this, check out Enterprise Architecture.  Simply put, business leaders and especially executive management need to be aware of everything besides the business layer that makes their decisions work.

Leaders’ decisions, changes in strategy, or business initiatives add workload for everyone outside of the normal level of work.  If the amount of work increases too much, people put in more hours to get things done.

When we look at the organization according to the diagram, it is simple to see why organizational leadership needs to look at the business through a holistic view of the enterprise and not just the business layer. Of course, it might be hard for leaders to think of the company at a level of detail that encompasses everything. 

This is why having people that specialize in representing these levels abstractly makes sense.  As projects get created and go through their phases, having someone document the underlying capabilities and system architectures allows the executive level to see what has changed.   Such as did they gain new capabilities or weaken existing ones? The leaders need a way to know what the organization’s capabilities are.  These documents then get stored in a body of knowledge which helps the organization in the future.

If the organization cannot throw additional resources at projects to create new capabilities, then it becomes a zero-sum game; adding or strengthening a new area means prioritizing that project over existing resources or capabilities.  Often this prioritization falls to IT, who comes across as a Debbie-downer because someone will not get attention.  Executive-level prioritization needs to happen to avoid this stigma.  In fact, the executives need to say no more often to allow the company to be innovative, which is what Steve Jobs did with Apple.

What about Innovation?

To get to a place where the organization can innovate, they must get all of these things aligned and properly balanced.  People should NOT be working at 100% capacity, meaning they cannot take on additional workloads; this should be common sense, but sadly, most managers think running at 100% capacity is good.  Granted, that might be true for a factory with large amounts of repetition, but even those have less repetitive tasks due to automation.

In Summary

If you want people to innovate, give them time and space to do so! Set appropriate expectations for the business, do not overburden your employees.  If they are overworked, do not expect good ideas or good work to come from them.  IT and the Business need to be the same; everyone needs more awareness of their capabilities and capacities.  Lastly, executive leadership needs to be aware of their employees’ workload to create the next innovation and should not be afraid to say no.

I want to hear some of your stories, positive and negative, please drop me a note.


SQL Server Error 823 Troubleshooting and Resolution

SQL Server Error 823

If you are getting this error, chances are you are having a hardware failure on your server, or perhaps someone deleted one of the database files.

Assuming you took care of that situation:

Do not Detach the Database

The very easy fix to do is to simply restore the database using your backups. But if you don’t have a good set of backups, Paul Randal ( he and his wife Kim, are SQL GODS) has a great set of steps to try in his article here.

Here is the short story of how to get your database up and running if your transaction log was damaged.

Error 823 Resolution

Switch the database into the emergency/single-user mode:

alter database <dbname> set emergency;
alter database <dbname> set single_user;
dbcc checkdb(‘<dbname>’,REPAIR_ALLOW_DATA_LOSS) with all_errormsgs, no_infomsgs;
alter database <dbname> set multi_user;
alter database <dbname> set online;

The main thing to realize here is that if the transaction log is damaged or missing that the transactions are not going to be found in the transaction log. You are going to lose any active transactions that have not been commited to the database. The real area of interest is the REPAIR_ALLOW_DATA_LOSS. This particular arguement allows you to recreate the transaction log. Do not take this command lightly as it will lose data, so please use it only as a last resort.


DBA Test/Development Server Best Practices

These are things I learned from a hardware failure of a test server (you might also call it a staging area). So what’s the big deal? Developers should have all their code checked into source control and nothing critical should be on there right?

Sadly no. These are things you should do on your test server to limit your exposure as a DBA.

1. Treat the server as a production server. This includes transaction log backups, backups of user accounts, SSIS, SSRS, SQL Agent jobs, and Windows Tasks.

2. Trust, but verify. Trust the developers to be following best practices, after all your job is to make the company money and so is theirs. Periodically issue correspondence with the developers to verify that nothing is running in a production manner.

3. Get a good snapshot/system image from time to time. If someone or something destroys your server, you have something to fall back upon. This is especially true when developers are creating lots of dependencies in their code to OS level libraries.