Thursday, July 10, 2014

Think Strategic and Act Tactical!

Being strategic with technology means treating your IT plans as a living and breathing organism that needs fed and nurtured. There is no auto-pilot, or silver bullet. Technology needs to align with business strategies to achieve optimal results. When the technology strategy supports business goals, the business can be agile, execute its strategies, and seize new opportunities.

From an information technology perspective, small organizations tend to be more streamlined and agile than their larger counterparts. In my experience, part of this reason is because they don't have the complex requirements of larger organizations. They can be more efficient by focusing resources on visible projects that directly add business value. They don't have the underlying scale and bandwidth issues that convergence creates, nor the complexity of a large scale distributed security model. I do think we also need to differentiate between those activities that are necessary, and those that do not add value when compared with the true cost of their delivery. I'm a big fan of keeping it simple, except when the added complexity better prepares you to respond to future opportunities.

In large organizations, technology is like an iceberg. The part that everyone sees and evaluates is the ten to twenty percent above the water. The eighty or ninety percent of the iceberg under the water is necessary to support the technology strategy in a complex, diverse environment. Your actual percentages aren't as important as the analogy. Above the water, we have the user facing outputs. These include outputs that enable the business to deliver its products, and data that supports sound decision making. Your business produces a product or service that adds value, such as knowledge gained through online learning, a cheerful living space supported by large architectural windows, or confidence while working in an underground mine that's protected by a trusted roof support system. What is your contribution to the business?

What is the part of the iceberg that's below the water? Well, that's all of the things we do every day to get to the point where we have a strong foundation of technology that permits agility and responsiveness to business
opportunities. The eighty to ninety percent? These are the things that business executives take for granted, or don't know that are needed to support visible services. They want an integrated communications system, and don't need to know that its supported by an SMTP, POP3, or IMAP server. They want secure access to information on the web, without knowing about firewalls, proxies, and virus protection. They want to know how many widgets they sold, and don't care about the database, operating system, network, switches, VLANs, or programming language necessary to deliver actionable information. They want an end product. It's our responsibility to plan for the 80-90% below the surface. We need to act as if we are selling a solution that adds value to our organizations. As experts, we should act like an auto service center, and not like an auto parts store.

Companies with a vision know where they want to be in five years, and they are executing steps in a business strategy to prepare them for success. As technology professionals, we need to know that destination and milestones along the way, so we can be prepared to support opportunities as they arise. Businesses cannot wait for us to build the 80-90% below the surface, they can barely wait for the 10-20% above the water. That's where we need to be strategic. Oh, and the difficult part... is convincing businesses that they need to invest in the 80-90% so that we can be agile in delivering the 10-20%. It's like building a house. You may be ready to sleep in your new bed at your soon-to-be-built home. However there is a lot of preparation, planning, and construction necessary to build the foundation, walls, roof, and the rest of the house. All of this needs to be completed before you have a place to put your bed, and get a good night's sleep.

I've had many conversations with business executives and leaders over the years, and there's one question I've asked that has solicited many different responses... "Where do you see this company in five years?" Organizations with a well thought strategic plan often asked follow-up questions... such as... are you talking markets, products, or growth? Companies that lack vision often struggled to form a response beyond they want to survive, or want to grow, yet lack any cohesive planning to support their goals. Follow up questions on how IT can support that strategy are often met by vague answers... and questions of why it's important for IT. There is a perception that IT is only the 10-20%, and "can't they just let us know when they need the service?" However, it takes careful planning and execution to build solutions to enable success.

I've learned over my career that as leaders, we need to maintain targets to focus and challenge our teams. This is our strategic direction, it's where we believe we need to be at different milestones over five years to support realization of the business plan, with some type of agility. It's much easier to get a good night sleep if I have a place to put the bed, and don't need to wait for someone to dig the foundation. We should be judged on the quality of services we provide, not on heroic efforts that mask a lack of vision and strategic planning. We cannot provide reactionary excuses for why we can't deliver results by tossing grenades over the wall and blaming others. It's our responsibility to ensure that we can support our customers.

Milestones form the tactical piece. It's important to provide deliverables, and to keep a pulse on changes that may affect the overall strategy, or business landscape. By acting tactically, and thinking strategically, we can develop digestible projects and milestones that form steps in getting to our final destination. We should get feedback from the business as we deliver interim "services", so we can adjust the strategy to support changes, and adjust our trajectory as appropriate.

I do believe in developing multi-phased long-term projects, with periodic planned releases and milestones. Based on the project, we normally establish bi-weekly or monthly working group meetings. I've found if you want to deliver projects that meet the customers' requirements, have your technical team provide frequent updates and get feedback. You'll often discover requirements that may not have been communicated, or interpreted correctly... and can be adjusted before they have any significant impact on your project.

In summary, thinking strategically is equivalent to knowing that you need a place to live, and planning each phase of construction. Acting tactically is the business of construction. It's delivering milestones like excavation, masonry, framing, plumbing, electrical, roofing, and finishing work. If you find that you're building on a slate outcropping, you can adjust. If the weather delays framing, there is also an opportunity to revise your plan. You can add resources, sub-contract, outsource, or decide that the delay is acceptable. It's all about understanding that plans should be living organisms that evolve with business requirements. There isn't a one-size fits all solution, and different organizations have different requirements based on size, geography, organization culture, economics, market, product, and other factors. Plans shouldn't be put in a drawer and revisited once a year.

That's it for this post. Remember, think strategically... and act tactically!

Wednesday, June 11, 2014

Technology as an enabler!

I've had several conversations with my staff recently.  These conversations were about technology.  I find that often people get caught up in the business of technology vs. the technology of the business. The difference is subtle, yet important.

I had an opportunity to have a recent conversation with my son, a Penn State student who was reviewing for an upcoming exam covering technology.  It was a little technical, from my opinion, for a Hotel Restaurant Institution Management (HRIM) Major.  He asked me the difference between a CTO (Chief Technology Officer) and a CIO (Chief Information Officer).   My prospective has always been that the CIO straddles both disciplines... the CTO, however, is more firmly situated on the technical side of the house.

CIOs are people with one foot in the business, and another in technology.  They focus on ensuring that technology projects are properly staffed and funded, and align with the requirements of the business.  They are not fully a business executive, nor a technology executive.  They can provide technology leadership and bridge communications obstacles between technical and business leaders.  This may include requirements for improving inventory turns, integrating new acquisitions, or speeding receivable collections.  They are savvy in justifying the need to invest in technology in a way that's easy to understand for business executives.  They are "bilingual", and can communicate with both technical and business leaders on their levels.

I'm in an ITS Collaborative group.  We've recently been discussing the differences between roles.  I - information role, with a business focus... IT - one foot in each discipline, and T - with a fully technical focus.  Depending on your customers, there is a requirement to meet them on their terms, and discuss their needs using terms familiar to their discipline.  Where are you?  Are you an I, IT, or T?  Or, does it depend which project you're undertaking, and which customer you are engaging.

The bottom line is simple, in IT we must provide a service and add value.  If we cannot communicate with our customers, then we will be unable to meet their requirements.  We should be trained on optimizing business process by reviewing them with an fresh, independent perspective.  Technology should enhance an add value to a business by streamlining processes, improving access to data, and empowering continued growth for a business.  We need to be able to identify the value we add, and communicate payback on technology investments using terms common to the disciplines we serve.

Let's talk performance...

Ok.  I admit it.  No matter how much I try to position myself as a pure business executive, I sometimes have a tendency to revert to my inner geek.  You know, it's that conversation that switches to performance, and all of the sudden, you remember everything you've learned about performance.

So, I thought I'd make a few general observations.  I was reading an article on Linked-In today, about how some people make assumptions that everyone else knows what they know... or that some of this stuff is just common sense.  I think sometimes I fall in that group.  So hear goes....


  1. The more you expect from a system, the more effort you need to put into tuning it properly.   E.g. it's easy to run Microsoft's SQL Server.  It's much more difficult to do this at a very large scale.
  2. Just because a system can auto-tune itself, it doesn't mean that it's can be much better with a great performance tuning expert.
  3. It's really easy to make good software suffer from a performance perspective, and then blame the software.
  4. There are MANY people in this world that claim to be expert.  They are so overly confident that they have convinced themselves that they are the ONLY competent people.  There's always someone smarter, better, and probably with better people skills.
  5. Databases like lots of dedicated memory.  If you have it, make sure it's preallocated and tuned properly.
  6. Databases like lots of IOPS.
  7. Faster spinning disks get more IOPS.
  8. More spindles /disks gets more IOPS.
  9. Proper raid level planning is critical for performance.
  10. Selecting the correct raid level has a significant impact on performance, and needs to be aligned to the purpose required.
  11. More cache is a good thing.
  12. SSD helps performance when properly configured to remove bottlenecks.
  13. SSD normally goes through a controller, PCI Solid State drives  are on the bus, and have an opportunity to run much faster.
  14. PCI SSD, properly planned, and with a recovery strategy can reduce the need for lots of spinning disks.  They do need to be part of the recovery strategy, should your PCI SSD fail.
  15. There is a tradeoff between faster processors, more cache, and more cores.  Evaluate this and make the best choice for the load profile.
  16. Database planning is important.
  17. Database tuning is required.
  18. Database recovery requires log files.  You can't roll forward if you don't have a full backup with all of the incremental log files.
  19. Database backup strategies can include cold backups, or a combination of logs and exports, and varies depending on uptime, and acceptable downtime and data loss.
  20. Networks must be properly planned in order to be both secure, and to scale properly.
  21. Firewalls are critical to securing a network.
  22. Performance testing much be consistent, and repeatable.
  23. Production environments must be monitored and tuned.
  24. Systems must evolve, users aren't static, and neither should be our systems.

I could go on... It's been a while since I posted, so I thought I'd do a quick performance memory dump tonight.  Thanks to this, I can now switch back to focusing what's important to the business, and being more leaderly.

Wednesday, February 12, 2014

What does it take to succeed?

Team skills and culture play a critical role in the success of projects. I have a group of dedicated developers that leave their egos at the door, and work together as a cohesive unit. We are looking for ways to continually improve our overall skills and improve our processes so we can be more effective in managing our projects. We ask for continuous feedback from our customers and adjust our project trajectory as appropriate. We focus on the little things, and try to monitor the pulse on our project to expose potential surprises early, so we can work with our customers to compensate for these changes. Project success is about focusing on how we add value to our customers, and trying to improve this every day, through an iterative approach.

Regardless of the development technique to which we subscribe, if we don't add value and serve our customers, our techniques, and results, are basically irrelevant. We need sufficient process to predict project outcomes, without constraining our potential for success. We need to use common sense and moderation to identify the correct balance for our individual teams.

Here’s some of my basic observations on what it takes to succeed…
  1. A dedicated team, and an honest feedback loop – the team is organic, and should feel safe to provide feedback on shortcomings, potential for improvement, potential new techniques, and strengths that can be leveraged.
  2. An ego-less culture – staff must be comfortable to brainstorm and provide feedback, regardless of level.  They truly value each other’s opinion, and look for ways to continuously improve processes.
  3. A focus on quality, openness, and customer service.  It means sometimes accepting responsibility, even when you may not agree that you are at fault… as a way to move forward.
  4. Focusing on the customers’ project, and talking on their terms… in their language.  They need a solution which they can embrace and understand, and not a bunch of technical details which are important to deliver the solution... yet are NOT the solution.
  5. Really understanding what the customers’ needs, and asking probing questions to help define and agree up front to the project scope and document the assumptions / specifications so scope creep can be identified.
  6. Prototype to get buy-in from the customers… and work with them to adjust the deliverables, resources, or timeline as appropriate.  If the scope changes, negotiate one of the above variables to keep the project on schedule… and provide immediate feedback on impact to your customer.
  7. Put together a detailed project plan… with a clear critical path… e.g. 1000 hours out of a budget of 2000 may be 10% complete or 50%... if you can’t tell, then break the project plan down further… and also rely on feedback for % effort complete, don’t go by hours alone.
  8. Frequent meetings with your customers to show current progress and get feedback.  You’ll find that they often missed important details as you demo project progress at weekly, biweekly, or monthly meetings.
  9. At every meeting, update your timeline… if there are risks, identify them early, and discuss them with your customer.  I would want to know early if my house won’t be finished for a few more weeks… not after I have the moving van packed and I’m on my way across the state.  Give your customers the same courtesy.
  10. Evaluate new tools and techniques.  Pick some unobtrusive way to test these, and adopt new processes and techniques after you've proved their value.
  11. Find ways to innovate transparently.  One of the recent things we've done is to deploy code without an interface, and off… so we can evaluate performance with the function enabled, and not visible.  It's easier to remove this via a setting, and the customer isn't disappointed because a feature needs refactored to perform at scale.
  12. Recruit and develop your staff for success.  Get staff that share the same dedication to customer service, and make them comfortable in your environment.  Look for team players, and provide them continuous feedback.  Reviews should be a reinforcement of feedback you provide on a daily or weekly basis… and nobody should be surprised… or there is a management failure.
  13. Quality should be part of the process, as should involving customers in the testing and acceptance lifecycle.   It shouldn't be an afterthought.  If we consistently require heroic efforts, then we need to review to see where we have failed in the planning and communications process.
  14. Ownership doesn't end when code is submitted, it’s a lifecycle approach, and shared across the team.  It’s part of that continuous feedback loop.
  15. Recognize your team for their results, and make sure they get the credit that they deserve.
In the end, it’s all about finding the right balance of tools, processes, and techniques to improve the services you provide your customers.  Ask, and get feedback... and be sure that you are capable of humility and openly accepting all comments.... even those for which you may passionately disagree.  Perspective and lens are individual, accountability and goals are not... so keep your eye on the prize and evaluate against measurable results, not effort.

Tuesday, February 11, 2014

Research Projects vs. Continuous Improvement for Production Services

There should be a clear distinction between a research project and a production service.  I’d like to do a brief contrast and comparison of where these overlap, and where the concepts diverge.  Let’s say a developer want’s to introduce a new process change into the development life cycle, or into the hosting life cycle.  How do you define if what’s being change is part of continuous improvement, or is a research project?  There are several litmus tests…
  1. Has the technology been proven in a pilot process, and is there a direct proven benefit to product quality, stability, and customer service?
  2. Is the outcome learning or proving the value of a technology?
  3. Has the technology been proven, and is the application of the process or technology easily repeatable for other applications?
  4. Is there a measurable benefit, and is the risk from the change mitigated with an expected benefit?
To contrast and compare…

AttributeResearch ProjectsContinuous Improvement Project
Expected ValueKnowledge, any other value is a bonusEither explicit, or intrinsic improvement
Cost Recovery ModelSunk / No Option for RecoveryThere is a payback or cost recovery period
Proven TechnologyProves HypothesisYes, this is either an application of a technique to a new system, or an evolution of an existing process.
Known OutcomeNo, the potential for improvement may be radical, however the risk is unknown.Yes, with a very high likelihood of success
Level of RiskHigh, first tested on low impact situationsLow, the technology has been proven.
Production ReadyNoYes

A continuous improvement project is one that improves on existing processes in a risk-mitigated fashion.  It is evolutionary in nature.  Research projects are attempts at revolutionary changes to processes, and are equivalent to a larger scale lab project to learn more about a process, and to evaluate the potential for improvement.  Once research projects have been proven, then the new process is mapped to existing processes, and a gap analysis is completed.  As part of the gap analysis, production processes are compared as evolution using moderate steps through continuous improvements to reduce risk.  Research projects are similar to a petri dish experiment… and can be anything from a proof of concept, to a radical change in processes or technology.

Because production services are expected to be stable, changes are introduced using a method that reduces risk.  The change is normally evolutionary, with prior proven steps, and a proven change management process.  Once the research project has proven successful, then it needs to be mapped, and evaluated based on its potential as a production service.  This means looking through the lenses of stability, customer service, process improvement, efficiency, and value.

I’m not adverse to radical changes.  However these should be first proven on services which have a higher tolerance to disruption, and then migrated up the service chain.  The exception of course, is when you are not meeting service commitments for a critical service, and can take a measured risk that the radical change will improve the service.  Unstable systems have a different criteria for change than proven stable systems.  There are a number of reasons why a system can quickly become unstable, including changes in infrastructure, rapid adoption, and inadequate sizing – all of which should be mitigated, where possible, with adequate testing.  Like the commercial from a few years back… if you click the go-live button, and you are an overwhelming success beyond your wildest dreams, you could have a scalability and stability issue you need to address with radical changes.

That’s it for now… Happy Computing!