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

Automating programming in a self-aware enterprise

 

AI.pngThere was an interesting article in NewScientist about a new approach to providing computing capabilities, computers with human-like learning that will program themselves. They talk about new approaches for computers to program themselves.

 

Earlier this year when ‘the machine’ was announced at HP Discover, this scenario was one of the first things that came to mind, since memristors can be used to provide neuron-like behavior. When you have universal memory whole new possibilities open up. When I saw the NewScientist article, it did make me think about a number of applications in the enterprise, since these techniques will be as far beyond today’s cognitive computing as today’s approach is from the mainframe.

 

Always bet on the machine is in a post from 2008, that was contemplating the future of development. What I probably meant was: those who learn to work with the machine will still have a career.

 

I’ve mentioned before that much of today’s management function is ripe for automation. With approaches like this, an enterprise autopilot is conceivable that can optimize a businesses’ response to normal business situations. Questions probably has more to do with ‘when’ than ‘if’.

 

Has the agile caused a reduction in critical thinking?

 

thinking.pngLately, I’ve been talk to some folks about problems they are having in their production environments. As I talk with them about the issues they encounter it seems clear they don’t even know their environment well enough to ask the right questions, let alone answer them.

 

Critical thinking skills were something where a great deal of work was focused on when computing resources were scarce and thinking time was relatively abundant (because you were sitting around waiting for code to compile). Now those forced breaks are rare, so people spend their time iterating through the coding process without having a chance to take a step back.

 

I don’t think agile techniques should cause a reduction in critical thinking, but I just see the potential is there to not really understand the architecture, the business rational… - since most developers are now so enamored with having working code. If you’re properly doing code reviews/walkthroughs you can outsource some of that big picture work to someone else and you’re forced to think it through.

 

Lately I’ve been looking at Lean Six-sigma techniques and applying them to operations management. This view is not anything new, but the abundance of computing capabilities should allow us to drive the costs out of its application. This technique usually involves asking these same kind of big picture questions although operations is a bit late in the process for that.

 

Do you see these issues too? What do you do about them?

 

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.

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.

Agile development - is it right for you?

Barrier break through.pngThe other day I was talking with a team about Agile development adoption. One of the things they asked was “What’s different?” and "Is it right for us?" I sat down and jotted this list of thoughts that came to mind. No, my response isn’t the purist perspective covering all the elements of the agile manifesto, but some might find it useful:

 

Agile focus:

  • Small cycles with fast turnaround - iterative releases w/improved time to value

  • High-level of interaction with the end user/owner

  • Progress centric, where business value is measured by tested, demonstrable deliverables

  • Transparency

  • Fail early/fail often – “defects” are an opportunity for a future release

  • Priority focused, with quicker realization of business value

It requires:

  • Direct access by the agile team to business users

  • Executive sponsorship, support and expectations

  • Customer commitment/involvement – if the customer isn’t there, the work can’t get done.

  • Automated testing (you’ll be testing more often so plan to automate)

  • Projects started with the awareness and assumption that you don’t know everything about the end result

  • Define areas that cannot be compromised (e.g., security) that need to be baked in along the way

  • Agile readiness assessment before each new effort – all parties need to be ready

  • Organizational change management (there is behavior change of individuals, leaders, relationships)

  • Priority-driven development

What remains the same:

  • Scope (scope will change, but if it changes too much, it becomes a new project/sprint)

  • Requirements (still need to be documented and tested) although they are not there at the start

  • Leadership and project owners (they accept or reject results)

  • Amount of potential work to be done (there is always going to be more to do, focus on value)

  • Budgets – projects still need to live within financial constraints

  • Performance measurement (what and how you measure will be different).

  • Documentation (the documentation is richer, since it should be completed all along the way).

  • Architecture (everything still needs to work together)

  • Change control (prepare for continous change)

What needs to change:

  • Incentives, compensation for the members

  • Governance processes and approaches to release and acceptance

  • Interfaces to other groups (they need to be more flexible)

  • Coaches and agile experience (for the ‘customer’ as well as the developers)

  • Continuous engagement level of business users

  • A view to develop and implement what is needed, nothing more

Although Agile has been around for well over a decade, a solid foundation for discussion still needs to be agreed upon.

Search
Showing results for 
Search instead for 
Do you mean 
Follow Us
Featured
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.