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

Will there be a new dimension to UI design based on cognitive computing?

things.jpgI recently read a report on How Humans Respond to Robots that focused on the social side of robotics. Near the end of the article it started to talk about autonomous cars, autopilots and other devices that are really robots but we don’t normally think of them that way (e.g., smart thermostats) because of their minimal user interface.

 

In a world where we’ll soon have wearable technologies all around us, likely building to a $50 billion market by 2017, pumping out data to feed the autonomous response of cognitive computing, it does make me wonder how enterprise architectures and application portfolios will drive us into the uncanny valley for business automation.

 

As we automate things and find patterns, the automated response could be a bit eerie and unsettling. Likely a new dimension for User Interface Designers of the future will look beyond just the traditional capabilities and more deeply into user intent and the sense of user interactions – so we can accept the assistance as intended.

Does personal accountability need to shift in business?

security.pngAs business and IT continues to merge, we need to increase the vigilance and expectations of everyone. A recent article titled: Treat IT architecture as a weapon talks about how the US military should start to treat the network and IT resources in general as weapons systems. The same can be said on the commercial side of business.

 

As we move to a world with high-powered analytics, and deep, data-based understanding enabled by the IoT, the models, architectures and assets need to be viewed as the serious differentiator for the business they actually are. When the network is breached, a root cause analysis needs to be performed and individuals held accountable. The responses of “I didn’t know…” or “I am not in IT…” need to be a thing of the past.

 

In our personal lives, we know we have responsibilities for our data usage and access. We need at least that same level of accountability in our work lives as well. We all need to be vigilant and help each other understand the implications of our actions. Security awareness needs to permeate the work environment – it is not just someone else’s concern.

Start small but think big, when transforming

StartSmallThinkBig.jpgYesterday, I posted about how we’re half-way through the current stage of IT and mentioned how IT needs to change. Today, I saw an interesting post from McKinsey & Company that has some similar views: Reinventing IT to support digitization.

 

They have identified seven elements critical to IT performance improvement:

1)      Clear, central business leadership on digital

2)      Elite IT talent

3)      Sourcing arrangements to scale the workforce rapidly

4)      Agile development and rapid releases

5)      Rapid innovation architecture supported by stable services

6)      Scalable cloud-based infrastructure

7)      High-quality integrated data

 

I agree with all those points, although I’d have dropped off the ‘on digital’ from the first point. I think all too often we continue to unnecessarily isolate the information technology goals and efforts from the business.

 

The article went on to describe a two-speed approach to transformation. This is one area that is as much about risk control as providing new capabilities. Start small but think big – is probably the rule. We can’t change everything at once and when making this kind of change, you need to develop experience.

This was driven home to me the other day when I was talking with my son (who teaches on-line). He was looking for a way to contact his students in a flexible, yet automated fashion. I said “Oh, no problem. I’ll just write an app for your phone.” I’ve written apps for a number of different mobile platforms over the years, so I thought it would be easy. I laid out a storyboard of the various screens. I bounced requirements off him. I knew exactly what I wanted to do, to make it look professional.

 

I dug into coding the first prototype. It seemed everywhere I turned, the Android environment didn’t want to support me in my efforts. It just didn’t have the fundamentals in the OS that I needed (or maybe the way I wanted them). So, I started to break the application down into various components that I could understand, validate and execute. Eventually, I will stitch them all together into a final application, but my first goal now is to get something dumb and functional that he can play with – without all the bells and whistles that were in the early design. A page out of any Agile Development handbook.

 

The same approach is needed as an organization starts to tackle its larger business support role and reinvention of its application portfolio.

Dimensions of assessing an agile architecture?

measurement.pngI keep hearing that organizations have greater expectations from their IT organizations than are being delivered. Shadow IT is the response as the business-side of the enterprise decides to go-it-alone. Many times those investments are done in a relative vacuum when compared to the rest of the organization’s portfolio.

 

As businesses move to be more agile and make better informed decisions, the focus is on being flexible in a number of dimensions:

  • Location – where and when works takes place
  • Social – relationships with and between customers, partners, devices and employees
  • Secure – what, why and how much in good enough
  • Process – for the past, now and in the future
  • Insight – what is and will be happening, and why

In continuing to think along the lines of the post on agile architecture, it makes me wonder how an architecture can be measured along these lines in the dimensions of time and value. Even though the requirements for the architecture can’t be nailed down do the perspectives (like those listed) remain constant? Should we also build into our thinking how long we think the architecture element is viable? That can be a tough issue as evidenced by the continued contributions of mainframes, COBOL and other technologies that are pretty far along the ripe cycle.

 

I recently read a thought provoking article titled: Management in the Second Machine Age that made me wonder about the effects of automation on IT architects as well. If you can measure it, you are closer to being able to automate it.

Is an Agile Architecture in your future?

agile architecture.pngA few weeks back I did a post on agile development and that got me thinking about the future of architecture and the need for agile architecture.

 

The same pressures of shifting needs are present at the macro level and should affect the creation and use of architecture work products – although since it is architecture it will be a bit different than agile development.

 

Some of the same principles apply:

  •          People – Architecture lives at the intersection of business and technology. People are at the focus of that intersection, not technology. Architectural efforts should focus on the effect upon the people involved. What needs to happen? How will it be measured? These factors can be used to make course corrections along the way – once you realize that an architecture is never finished. If it doesn’t deliver as expected, change it. Make the whole activity transparent, so that people can buy in, instead of throw stones.
  •          Continuous change – When you begin to think of the business as dynamic and not static, the relationship with the real world becomes clear. In nature those species that are flexible and adjust to meet the needs of the environment can thrive – those that can’t adjust die off.
    Architectures need to have standards, but it also needs to understand where compromises can be made. When talking with CIOs the other day, it became clear that ignoring Shadow IT efforts doesn’t mean you will never need to support them. It is better to understand and facilitate their effective use (through architecture), rather than try and stand in the way.
    In a similar way, the link between the agile projects and the overall architecture need to be recursive. Building upon the understanding that develops. The architecture does not stand alone.
    Architecture development can also have short sprints of understanding, documenting and standardizing the technical innovations that take place, while minimizing technical debt.
  •          Focus on business goal based deliverables – Over the years, I’ve seen too many architectural efforts end up as shelf-ware. In the case of architecture, just-in-time is probably the most effective and accurate approach.
    If the architecture work products can be automated or at least integrated with the tooling used in the enterprise, it will be more accurate and useful. The concept of machine and human readable work products should be part of any agile architecture approach.
    From a goal-based perspective, the architecture needs to understand at a fundamental level what is scarce for the organization and what is abundant and then maximize the value generated from what is scarce – or at least unique to the organization.
  •          Good enough – Don’t let the perfect architecture stand in the way of one that is good enough for today. All too often I’ve seen architecture analysis go down to 2 or 3 levels of detail. Then people say “if 2 is good, let’s go to 5 levels of depth.” Unfortunately, with each level of detail the cost to develop and maintain goes up by an order of magnitude – know when to stop. I’ve never seen a single instance of where these highly detailed architecture definitions where maintained more than 2 or 3 years.
    The goal should be functional use, not a focus on perfection. Architecting the simplest solution what works today is generally best. If you architect the solution for something that will be needed 5 years out, either the underlying business need or the technical capabilities will change before it will actually be used.

None of this is really revolutionary. Good architects have been taking approaches like this for years. It is just easy to interpret some of the architecture process materials from an ivory tower perspective.

Search
Showing results for 
Search instead for 
Do you mean 
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
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation