The Next Big Thing
Posts about next generation technologies and their effect on business.

Strategy, Execution and IT

strategic thinking.pngRecently, I was looking at a video about business strategy and execution from the Strategy+Business blog. It talked about the five major questions a business strategy needs to answer:

  1. What businesses should we be in?

  2. How will we add value to that business?

  3. What is our target customer?

  4. What’s the value proposition for those customers?

  5. What are the capabilities we need to be distinctive for those customers?

It also discussed how easy it can be to confuse what it takes to execute a strategy with the strategy itself (e.g., a plan).

 

The video made me think about the role of IT today and how it may be perceived. Do we look at our various investments from the perspective of answering these kinds of questions or do we just look to cut costs. That difference in behavior is one of the greatest differences between an IT organization that is crucial to the business and one that is just an enabler of the business.

 

Many times I’ve mentioned the need for portfolio management within the applications of an enterprise and the fact that it may be as important what you turn off as what you turn on. In a recent discussion with an analyst about Enterprise Architecture they really downplayed the role of the current situation analysis and listening to this video just reinforced how much this value added assessment of the current portfolio can be, since by turning off those systems you free up resources to actually be strategic.

 

The business should be able to relate to a decision based on this strategic perspective, since that’s likely how they think about what they deliver to the market.

 

When planning for the future it can often require an active decision to totally break from the past approach and try a new one. This can be very risky, but there are also risks hanging on to changes that are long overdue – because we’ve always done it that way.

 

Metrics and Enterprise Architecture

measurement.pngI was talking with some individuals recently about the changing role of architects. Although there are stills some organizations that are focused exclusively on cost cutting – doing more-with-less. There are also those that view the main role of the architect is strategic, improving agility and IT effectiveness. This has raised the importance of business architecture, looking at business process effectiveness, not just the underlying technical environment. This also means looking at how the IT available is being applied and may even mean doing more-with-more. Even in this age of cloud techniques, there is more need for Enterprise Architecture than ever.

 

Enterprise architects will need to deal with a new set of goals and measures, since the perception of their value and impact will be changing. Unfortunately, since many of these activities are longer term in nature that also means that they will be harder to measure and dynamic course correction will have greater latency.

 

The impact of efforts like application portfolio management can be easily measured but take a long time to become visible. Improved time to market is a bit more nebulous and can take even longer to become apparent. What’s clear is that the metrics need to be defined specifically for the situation. It is not a one size fits all efforts approach. I could be mistaken, so if you think there are standard EA metrics, please let me know. 

SDN: Software Defined Networks

sdn thumb.gifI recently facilitated a discussion where we deliberated the business value of Software Defined Networking. This was an interesting exercise, since I was trying to get those involved to move beyond the technology and give examples of why SDN is important to the business itself. In preparation for that discussion, I reviewed the book SDN: Software Defined Networks by Thomas D. Nadeau & Ken Gray among a number of other sources.

 

I found the material in the book to be a useful orientation to the current state of the SDN market as well as develop a contextual understanding of the flexibility provided and the approaches needed to build value through an SDN. One point made clear through reading the material is that one of the key benefits is flexibility. You’ll only internalize what that means to your organization through experimentation and using SDN. This is best summed up through the following sentence from the last chapter.

“Though it’s too early to pick a winning technology, or even a winning definition of SDN, one thing remains true—the explorations into SDN will change our present method of operation.”

 

This book facilitates developing that contextual understanding of what the possibilities could be so that you can plan the approach that works best for you. There is no one right answer.

 

One of the areas I thought could have been brought out a bit more is the strategic implications of SDN on enterprise service functionality and architecture. It appeared the assumption was that there are no real implications on the applications (that generate business value) themselves. It is all about data packets as network traffic being routed more flexibly.

 

There are business value generation areas to be explored that are enabled by SDN allowing network operations unique to data on the move. This is somewhat like the revolution that took place when object-oriented approaches (of the mid to late 80s) shifted how we viewed data class and instance unique processing, while at rest. Data-on-the-move specific processing may be a bit too esoteric for the target audience of this book though.

 

It is clear that the SDN market is at the early stages and there remain many opportunities to understand and address. I thought this book was a worthwhile addition to increase understanding.

Enterprise architecture now more than ever…

Reach.pngI saw this post by Tim DeGennaro about Enterprise Architecture in 2014 it made me think about a discussion I had with a large analyst firms Enterprise Architecture specialist. I mentioned to him that HP’s EAs are not focused on “selling” HP products. They are not part of central organization but instead tied directly to client organizations. Naturally, they have some interest in the product’s being used appropriately, but their main interest is in generating value for the company, within their business, meeting their goals.

 

During our discussion, we kept going back to this topic over and over. It was clear there was a contextual mismatch, since my view is that that there is no way an EA can push product off the back of the wagon and fulfill their role as a trusted advisor. His view was that HP is a product company and therefore the EA must sell product – even though I don’t think he agreed that perspective was best. It was just an assumption he made.

 

The EA needs to be focused on the long term value generation – and the analyst just couldn’t understand that this was our approach. HP Enterprise Services wants to have long-term strategic relationships with organizations (most of the EAs are in HP ES). We view that Enterprise Architecture is at the center of these relationships, whether it is based on infrastructure, applications maintenance and development or business process outsourcing, to truly generate strategic value an enterprise architecture is needed. Often HP personnel perform this function, sometimes the customer’s team carry the load - in any case, we see Enterprise Architecture as foundational to what we do.

 

Transformation journey.png

We look at enterprise transformation as a journey, starting with assessing the current state of IT and its alignment to and support for the business, along a path to a defined “new state”. A state based on the business goals of the organization, not on some product list.

 

One of the important functions of Enterprise Architecture is to communicate the destination as well as the steps and the governance needed along the way. This allows for fact-based expectations, discussions and actions -- reducing confusion and rework. Organizational change management and communication skills are crucial to make this happen.

 

Since the EA deliverables need to be business driven – enterprise architect should strive to always tie back initiatives to business direction and metrics. Sometimes we all can lose sight of why we are here and this traceability helps keep everyone grounded in the needs of the business.

 

Once I was working at a large food manufacturing organization interacting directly with their Chief Technology office. We’d get into deep, esoteric discussions and I’d ask the question “How does this make more cheese?” to focus us back on the business goals.

 

Even though it may seem simple, the connections between the enterprise architecture and business goals allow EA’s try and maintain a practical approach. The architectural work products and the architects themselves need to be used effectively to deliver solutions and not be ivory tower shelf ware.

Networking and thoughts on systems of action

Odecisions.pngne of the major shifts underway whose implications are poorly understood by most organizations is the move to software defined networks. These networks are not like the traditional hard wired communications path we’re used to or even the autonomic systems of the human body, relying on rules that are predefined. They are more cognitive systems that enable and even make decisions based on experience.

 

The difference can be explained with the following example. When you are playing catch, you reach for the ball flying towards you. You position your hand based on previous experiences rather than calculations or rules. If you catch the ball, it reinforces your experiences, making you better. If you drop it, you change your behavior the next time. This approach is a foundational change what I include in my definition of systems of action.

 

We don’t know how to do this with software perfectly yet, but as computing capabilities increase and the algorithms improve, the application of these techniques is well within reach. Networking is one area where we’ll see it early, creating an Internet that is responsive to the changing needs of the day. Eventually expanding out to most business processes. The flexibility of SDN will impact how applications are written in much the same way that hybrid cloud and IaaS should influence the architecture of applications today.

 

Searching and sentiment analysis are other areas where we’re seeing these techniques applied today. Learning algorithms attempt to derive intent, moving to a negative response time where organizations can influence decisions and actions can be taken before the decision is made.

 

One of the major drivers for this adoption is the scarcity of attention in business today. These approaches will allow us to focus attention more effectively and filter through the torrent of information and more importantly the choices flooding us today.

Search
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels