Jumat, 23 Agustus 2013

Advanced Software Architecture Blog

Advanced Software Architecture Blog

A Roadmap to Business Agility

Posted: 22 Aug 2013 09:07 PM PDT

I hope my avid readers noticed that as I discussed Business Enablement and IT simplification in my last two posts (Business Enablement through Release Management and Achieving True Business and IT Partnership), there was a common thread that ran through both of these articles.  It was maximization of business agility.  But what is business agility and why is it so important?  In my simple definition, it is company's ability to react quickly to changing market conditions.  Every organization strives to introduce new products or services before its competitors, change prices at a drop of a hat, offer innovative solutions, be flexible, and so on.  Those companies that are more agile become leaders, those that are not become extinct.

I've argued that enabling business users to make changes to IT systems themselves and providing a streamlined deployment process goes a long way towards achieving business agility.  However, the more astute readers will note that there has to be a more holistic approach to achieving business agility.  And they would be right!  In fact, there are many approaches and models to maximize an organization's business agility.  Doing a Google search on "business agility" brings up hundreds of relevant articles.  All of them approach this topic from different perspectives, and all of them have merit.  In this discussion, I will present an alternative to maximizing business agility – simple, yet powerful roadmap to move the organization forward.

My model consists of two variables – Business Enablement and IT Complexity.  The hypothesis that is being proposed by it is very simple – by increasing Business Enablement and reducing IT Complexity, you will maximize your organization's business agility.  The visual representation of this model is shown below.


As you can see, on the way towards maximum agility, each organization will pass through a variety of states.

  • Highly IT Dependent 
    • Business depends on IT to perform even the simplest tasks 
  • Process Dependent 
    • All processes are defined and understood
    • Business and IT both follow consistent and repeatable processes 
  • Enabled & Largely Independent
    • Business is self sufficient in most operations
    • Needs to rely on IT in some situations 
  • Self Sufficient & Automated
    • Business can perform all the critical functions with little or no IT involvement
    • IT plays a supporting role

These maturity phases are all very high level, but you can see how and where the progress should be made to achieve the next level of maturity.  The maturation process makes business increasingly more and more self sufficient while at the same time mandating simplification of IT.  Without Business Enablement and IT Complexity variables moving in the right direction, the subsequent phases on the maturity curve cannot be reached.  The proof of this hypothesis is provided below.

The IT Complexity component of the equation has to be explained a bit further, as it carries a very specific meaning in this model.  There are many elements contributing to IT Complexity.  They may include number of systems, number of interfaces, diversity of platforms, supported technologies, etc.  My simple definition of IT Complexity is the amount of effort required to introduce a unit of change to IT systems.  A unit of change is a measure of a basic change that can be made to a system's functionality.  Each organization may have a different notion of a unit of change, which is why using this measure helps generalize this approach across a variety of IT organizations.

Some IT environments can be so complex and tightly interconnected that even the simplest change can take a lot of effort.  On the other hand, there may be organizations with such well defined systems and clear boundaries around them that changes can be made quickly with little or no impact on the outside world.  Most organizations, however, will find themselves somewhere in the middle of the two extremes.

The reason IT Complexity plays a prominent role in the business agility model presented here is simple.  The faster and easier that changes can be made to IT systems, the more agile the entire organization can become.  In fact, by simplifying the IT environment and introducing next generation technologies such as Business Rules, BPM, Cloud Computing, etc. you will decrease the time required to make changes to IT systems.  I've argued this exact point in the Death of Custom Software Development post.

The bottom line is that by striving to increase Business Enablement and reduce IT Complexity you will ultimately maximize your organization's business agility.  Why?  Simply because by increasing Business Enablement, you enable business to react faster to any situation, and by decreasing IT Complexity, you make IT more efficient.  Putting these two variables together leads to maximum business agility.

The path towards business agility is neither straight nor simple.  The distance between each maturity level on the model is measured in years, not months.  The journey requires significant investment of time and resources, strong backing of IT and business leaders, deep commitment from everyone involved, and a lot of hard work.  But the results are worth the effort.  If you had to choose between the market leadership, mere survival, or extinction, where would you want your company to be?  My guess is that market leader is where everyone wants to be.  To achieve this, you will need to follow the simple roadmap outlined above.

Read more...
Diposting oleh home architecture di 17.06

Jumat, 02 Agustus 2013

Advanced Software Architecture Blog

Advanced Software Architecture Blog

Business Enablement through Release Management

Posted: 02 Aug 2013 08:54 AM PDT

Ever since IT became self-aware (no, not like Skynet in the Terminator) it has been striving to make itself more and more efficient.  The "Aha!" moment for every IT organization comes when it realizes that business thinks it is too slow and delivers little value.  After much introspection, new promises are made, commitment to customer service is renewed, processes are modified and streamlined, resources are trained, and so on…  Everything runs great for awhile only to be repeated a couple of years later.

In the recent years, when the technology became more business user friendly, IT organizations realized that the best thing they could do for the business was to let it have a piece of the action.  "Business Enablement" became the thing to do.  The idea was to let the business users actually make changes to some parts of the IT systems.  According to James Taylor, a thought leader in the decision management space, "business enablement means putting the business users, those who understand the business and how it needs to change, in a position to make the changes they want and need without IT being a roadblock."(http://www.ebizq.net/blogs/decision_management/2006/08/heres_a_quick_way_to_deliver_b.php)

Many organizations have struggled with enabling its business users in the way James Taylor describes it.  Many have tried, yet many have failed.  Those that are successful not only introduce the right technology solutions but also modify many of its processes to ensure that business users can actually do what they need with little or no IT involvement.  Simplification and streamlining of the processes, automation, and modernization are the keys to a successful business enablement initiative.  Introducing the right business enablement technology is, of course, beside the point.

Typically, the biggest obstacle to making business enablement work well is the IT Release Management process.  It is often too rigid and cumbersome, requires a small army to execute, and takes a long time.  Business doesn't want to wait months for its often simple changes to be moved to production.  This is not what business enablement is all about.  Yet, IT, rightly so, doesn't want to let anything get into production without proper testing and validation.  And here, at these crossroads is where most business enablement initiatives die.

But there is a way to solve this…  The simple solution is to provide a shortcut to production for most if not all the changes made by the business.  The diagram below depicts a high level process for achieving this.


It really doesn't matter what tools are employed or what types of changes are made.  This process should be able to handle most situations.  The idea here is simple.  To streamline the movement of business artifacts from development to production, several steps need to be taken.
  1. Establish a Business Development Environment, a location where business users can make changes to elements of IT systems under their control and test the impacts of these changes 
  2. Once the changes are ready, provide an automated way to execute as many regression tests as necessary to validate that the changes do not impact any existing systems 
  3. Enable an automated way to execute performance / load tests to ensure that changes do not adversely impact established NFRs 
  4. Ensure stakeholders validate that the changes do not break current systems' functionality 
  5. Upon successful completion of all the tests, provide an automated way to deploy changes to production
Ideally, this process should take a few hours, a couple of days at the most.  It should shortcut the existing Release Management process that normally takes weeks to complete.  The goal is to introduce changes into production as quickly as possible.  Of course, not every change is eligible for such first class treatment.  The basic guiding principles for a shortened release management lifecycle should be:

  • If a change is confined to business owned elements only and no changes by IT are needed, the change is eligible for the streamlined release 
  • If any IT changes are required, the regular release management process should be followed

While this process is simple from a high level perspective, there is a lot of hard work that needs to go into it to make it operational.  Automation of testing and release management functions is never simple, fast, or straightforward.  It usually takes months or even years to reach a point where it will cover 80% of IT systems and business functions.  Yet, without automation, the process as described above cannot work.  There is not going to be anything fast or streamlined about manual testing of business changes.  On the other hand, the culture change required to make this process work can be daunting.  Not many IT organizations will be willing to make this kind of a leap.

Business enablement can be achieved without a streamlined release management process.  However, business agility cannot.  Businesses cannot move as quickly as they can and react rapidly to a changing business climate without a way to introduce changes to IT systems in days rather than months.  Those that can leverage business enablement and release management processes to their advantage will inevitably come out ahead.

Read more...
Diposting oleh home architecture di 17.21
Langganan: Postingan (Atom)

Subscribe

Followers

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP