Monthly Archives: April 2010

Sustainable Transformation

Posted on by

Business Process Management (BPM) and Continuous Process Improvement (CPI) are complementary initiatives and together foster business alignment. Successful and sustainable business transformation requires a programmatic approach that includes the technology of BPM and the methodology of CPI.

A programmatic approach to process improvement and management:

  • Fosters a close alignment between the various functions of the business and IT
  • Incorporates change management and program management
  • Ensures communication at all levels and
  • Establishes control mechanisms for sustainability

Having already become Certified Process Professional (CPP) and gained years of practice directing organisational transformation using Business Process Modelling, Re-Engineering and Management, the next challenge is to formally embrace LEAN Six Sigma.

And so begins my journey into becoming a Black-belt LEAN Six Sigma (LSS) expert.

My goal? To advise, guide and mentor organisations to achieve efficiency gains / savings by tackling waste management issues. With May 6 looming ever so closer and the political landscape about to change significantly across the UK, Sir Peter Gershon’s efficiency review will once again land on the desks of the CEO and CIO across all organisations – ranging from the SMEs to the Blue Chip companies who will be helping the government to claw back monies to help pay off our deficit.

See you on the other side 🙂

PS Don’t forget to vote before/on May 6, 2010. Use your vote wisely!

Becoming an Enterprise CIO

Posted on by

I’m in a Pensive Mood …

Working as an Enterprise Architect – I’m beginning to question my aspirations of becoming a CIO.

I’ve been affected by some of the recent poor experiences I’ve had where CIO was too passive and focussed on “short-termism”.

Is the role of the CIO dead or alive? Does the CIO still have an effective role/function in the age of Enterprise 2.0?

A decade ago CIOs were undervalued, overworked, under pressure and frustrated. They knew they could be leading their firms to new ways of doing business enabled by IT, but no-one would listen. Cynics of the time were fond of suggesting that CIO stood for “Career Is Over”.

My curiosity led me to carry out some research which opened my eyes and inspired me again.

Studies conducted by London Business School and CIO Development, BCS Elite, Certus and Computer Weekly confirm that the CIO is  indeed important. The CIO now enjoys a role and status that his peers from ten years ago would not recognise.

Navigating into the Enterprise CIO Position

Personal Characteristics

Successful CIOs have the same personal strengths we find in other senior executives. The role can accommodate the full range of leadership styles from extrovert, charismatic through to the gentler style of “people persons.”

When CIOs were asked as a group to list their most important personal characteristics these are the top four:

1. Good project manager or change manager

One of the most impressive CIOs I have worked with over the last 10 years is nearing retirement. When I asked him what he put his success down to he thought for a minute and told me “I am a good project manager who happens to understand IT.” CIOs are often among the best change managers in the organisation for this very reason.

2. Excellent communicator

Everyone by now must surely have got the message that if you talk like a plumber you will be treated like a plumber – but the truth is, relating IT to business in a compelling and engaging way, without using jargon, is difficult. This can be a very big deal to your CEO and executive colleagues so you must not fall into the trap. If all anyone at senior levels wants to talk to you about is IT you might be making this mistake. Most good CIOs claim to be better at the one-to-one but they are also highly competent in groups, and they are able to “sell” their vision both to their executive colleagues who will endorse it and to their teams who will deliver it.

3. Good leadership

Surely one of the most talked about and least understood executive issues – “leadership” – exercises and stretches CIOs a good deal.

Here are my top three myths of IT leadership:

  • Leaders are born, not made; it isn’t something you can learn.
  • The British are not generally good at leadership.
  • IT professionals tend to be introverted and task oriented. They do not make good leaders.

All these, and possibly other favourites you may hold dear, are hopeless generalisations that fly in the face of the evidence.

There are key distinctions between being a good leader and a good manager. Managers manage process and leaders lead people. This shows up most clearly in times of change and change is often, perhaps always what being a CIO is all about.

CIOs feel the strain of leadership and yet relatively few of them have taken advantage of formal leadership development. They should, it can make a big difference not only to their personal performance but to the team they are leading as well.

4. Stamina and Determination

It is interesting that this should come up as a top four personal characteristic – something that CIOs share with CEOs. There is a doggedness about good CIOs. They tend to be driven by some vision, or inner need to find a better way – often expressed as a need “to make a difference.” However they express it, it is a deep drive to improve things and they do not give up easily.

Critical Success Factors (CSFs)

Winning the trust of senior colleagues and using it as a basis for building relationships is essential because IT builds dependencies more quickly than other functions. Missed deadlines, undelivered functionality, cost overruns are all deeply disturbing to your executive colleagues and it is not enough to explain away the problems – they know that IT is tough to manage, they just expect you to buffer them from that.

A top class IT management team is essential and CIOs have to create the environment for talent to be developed and flourish. Try asking yourself the question: “Why would anyone choose to work here?” If you cannot immediately come up with a compelling answer ask yourself what you need to do about it.

A good and trusting relationship with the CEO is essential, and a trend to switch CIO reporting to the CEO was evident in the 90s but there are downsides to this. For one, he or she may be unwilling to get into some of the detail the CIO may want to share from time to time. But perhaps the most significant problem a direct reporting line can cause is it can breed fear and mistrust in your executive colleagues and this is self- defeating.

Last on my list of key factors for success is so obvious I nearly missed it. You must, of course, have the trust and support of your own team – and you shouldn’t take this for granted. There are many ways to inspire loyalty and to engender excitement and energy. You need to find your way – learn the techniques but be your own person. If you are open and honest with your team and you encourage them to be the same you will be creating a culture that will suit the best on your team and they will support the rest.

Benefits

So, given that the CIO is such a tough, lonely and perhaps unappreciated role why are IT executives queuing up to become CIOs?

First, if you are going to be anything other than a skilled technician (and plenty of people in IT prefer to remain exactly that) you might as well try to get to the top. The middle management of any discipline is an uncomfortable place and the true target of the Dilbert cartoons.

The higher up the hierarchy you go the more you get to influence what actually happens and at the top you can have so much influence it can be scary. One CIO recently confessed to me that he was elated to get the job after a major merger but terrified of what he had taken on. “At the beginning there was just me, the CIO – everything else had to be created”.

If that sounds a little like the beginning of the world then I guess that is what it felt like. Executives of all disciplines will tell you that to be a significant part of the creative process, to make a real difference, is probably their major source of job satisfaction.

A curious thing about being a CIO is that so few people have done it before and the rules are being constantly re-written. This satisfies a particular type of executive, those who revel in having to work out how and whether it can be done. This is a peculiar kind of intellectual risk-taking, similar to entrepreneurialism but without the terminal downside: until recently that is. With CIO tenures shortening all the time the post dot.com world might be different again. One thing is certain – the top IT executive job in any organisation is likely to get more not less demanding, and it is that that gets some people out of bed in the morning.

But perhaps the biggest motivator of all for CIOs is that they are doing the most important and exciting work that an IT career can offer, and all of us in IT work will know that is saying a lot. A good CIO, in a moving organisation will get a daily fix of leadership and change, technology and relationships. He or she will be frequently under-fire but will have the protection and support of those few in the organisation who have seen the future and want it created. They cannot do it without the CIO.

Take-Aways

To make the transition to top CIO, three skill sets are vital:

  1. business know-how,
  2. technological confidence, and
  3. high-order behavioural skills.

The last includes the ability to manage and facilitate change, personal communication skills, leadership, teamwork and the ability to influence others.

Although most organisations still haven’t got the message, an effective CIO operating at the top of the company is second only to the CEO in capacity to influence across a broad range of processes and functions, and is uniquely placed to influence the organisation’s future.

TOP PERSONAL CHARACTERTISTICS OF CIOs

  1. Good project manager or change manager
  2. Excellent communicator with individuals and groups
  3. Provides willing and effective leadership
  4. Plenty of stamina and dogged determination

CRITICAL SUCCESS FACTORS

  1. Win the trust of executive colleagues by keeping promises
  2. Develop people and really empower your teams
  3. Develop and maintain a good relationship with a committed board level sponsor
  4. Take the lead on important IT initiatives
  5. Give priority to maintaining the trust and support of your team.

Closing Comments

I breathe a sigh … and decide to continue towards achieving my aspiration. I want to become a CIO or a Cxx level director who really can make a difference to an organisation.

The best CIOs usually have a strong leadership profile. They weren’t born that way but like body-builders they have developed their leadership muscles until they are strong and fit for purpose.

My next step?

Focus on “leadership training” activities and pursue an Executive MBA (EMBA) to transform me from an accidental leader into a deliberate, practising one.

Monitoring SOA end-to-end

Posted on by

Introduction

For those organisations that have moved into live running of business applications based on SOA, one of the (many) current headaches is monitoring and managing end to end transactions. Although application, network and infrastructure monitoring tools have been around for many years, the loosely coupled nature of SOA presents some challenges in providing the transaction visibility, integrity and recovery capability that mainframe users have enjoyed since the 1970s.

Of course, this state of affairs is nothing new for an emerging technology standard such as SOA. The move from host-based computing to distributed client-server environments produced similar problems for transaction monitoring. The introduction of multi-phase commit functionality helped to provide better distributed transaction management.

Nowadays, application architectures typically have several layers that are not tightly integrated with each other. Most modern applications are accessed via a web browser across the internet/intranet, hosted on a portal server which in turn calls web services, possibly choreographed via an ESB, orchestrated by a process engine, run on one or more application servers, using business rules from a rules engine, calling legacy applications and databases on mainframes or servers in one or more data centres. And don’t get me started on where Software as a Service or Cloud Computing fits in…

So, when a web user of the business service experiences a problem (not responding, misbehaving, returning errors), how do we identify and rectify where the problem lies?

Enterprise Monitoring Framework

It would be a fair assumption that you already have an enterprise monitoring framework providing monitoring data on networks, servers, security, database, and some applications. The main additional requirements that an SOA environment might bring are: portal, web server, processes, enterprise service bus, services and an application server. For many of these components discrete monitoring tools are either built in or available. In fact, if any layer of your current stack is not instrumented you should consider replacing it with a product that provides the relevant performance statistics.

The two parts of the stack that won’t be initially ready for monitoring, not surprisingly, are the process layer and the services themselves. The runtime of the business process is typically either done as execution of Business Process Execution Language (BPEL) or within the black box of a specialist BPM tool. It is also possible that the process is being choreographed within the portal layer, or as an old fashioned program-like service running in the application server. Both of these architecturally unsound (but sometimes more practical) approaches still require the same monitoring instrumentation as for processes and services, as in all these cases there is limited built-in monitoring. Services, be they web services or other standard encapsulated code, are by their nature programs transforming the input into an output as specified. To find out what happens within a service, we need to ensure that the service tells us.

Therefore we are back to the old programming approach to providing insight to what is happening within code: alerts and flags. My experience is that currently you will still need to architect some code-based alerting into the processes and services. This is complicated by the need to understand the context in which the process or service will be invoked and consumed. One way this is done is by returning a status message containing the transaction ID to a monitoring console or database on completion of the task. If there has been a problem, an error code is typically returned that can be actioned by your service monitoring infrastructure. However, in the loosely coupled world of SOA, the specific service may be being used by a number of different business processes, so the response to the error condition will need to meet the particular requirements of this process.

To understand this context requires an overall End to End Service Management Strategy, comprising the following:

  • Business Service Monitoring Strategy  (BSMS) – This defines the business metrics and events that need to be captured and measured during execution of the high level business process or service.
  • Business Transaction Management (BTM) – In a traditional CICS-like Transaction Processing (TP) environment each transaction is managed to provide trusted commit, rollback and recovery. In an SOA world you will need to emulate this across the whole business process. Some of the more sophisticated process engines and ESBs provide tooling to reasonably easily enable the tracking of each transaction, and provide the audit trail to prove completion, or enable rollback of the transaction. However you will still need to define and develop the recovery procedures yourself to cover the round trip.
  • Business Activity Monitoring (BAM) – Even if the transaction completes there could still be performance issues or delays in returning the results of each transaction. This requires more detailed activity monitoring of each component of your SOA stack to identify potential and actual bottlenecks. As you can imagine, in a large stack there could be a considerable number of components to be monitored in the complete journey. Expecting your monitoring team to keep track of all of this manually is unreasonable. An automated script-based intelligent tracking system is required to meet the service levels your support teams or outsourcer will be held to.

Having been working on a large SOA transformation programme for the past few months, I have been working through the challenges of delivering this. If you deliver all the above will you achieve end to end SOA monitoring? My experience is that this provides the groundwork.

—

Original article written by John Moe, Head of Business Integration, TORI Global

Biography

John Moe, Over more than 25 years, John has managed a number of strategic transformation programmes for large companies, using ERP technologies, process improvement and change management techniques to ensure successful adoption and transition.

More recently John has consulted and mentored extensively on SOA and BPM, helping individuals, teams and organisations to understand and gain significant business benefit from these architectural approaches.

A former Gartner Consulting Director, John works closely with senior IT management to remove the perceived gap between Business and IT, using a synthesis of process, people and systems to make change stick.

New Web 2.0-inspired Workforce Tool from TIBCO

Posted on by

Workplace Collaboration Tool

As an ex-TIBCO employee – I’m always interested in new product launches which are always innovative. Read on.

—

December 7, 2009 – Today, TIBCO Software Inc. announced their new workplace communication tool called tibbr. Differing from enterprise search tools, tibbr offers a subject-based approach in which relevant information finds the users who need it.

With tibbr, built using TIBCO Silver – an application delivery platform for cloud computing – TIBCO aims to filter out unwanted information by keeping the focus on subjects. A tibbr subject can be a user, an application or a process relevant to a business user. Users get their information by subscribing to the needed subject feed.

“Employees don’t suffer from a lack of information; in fact, too much information is hurting employee productivity,” David Mitchell Smith, vice president and Gartner Fellow at Gartner Research was quoted in the release. According to Smith, workforce collaboration processes hold the most promise for productivity gains.

tibbr integrates with the enterprise system via a standards-based API that embeds enterprise social capabilities into systems or applications, and maps applications to subjects with scalability, security/encryption and high availability.

“By combining the best of social networking with TIBCO’s real-time expertise, business users can leverage tibbr to filter through the noise and receive information only once, making it manageable and meaningful,” said Ram Menon, executive vice president, TIBCO.

TIBCO employees will implement tibbr this month, and general availability is scheduled for early 2010.

Reading List

Read more about enterprise social networks in these recent Information Management articles.

IDC: Social Media in the Workplace

Get Real: Social Networking in the Workplace

Business / IT Collaboration Model: A Practical Approach

Posted on by

Introduction

The collaboration between the business department and IT department of an organization has been subject to research by many organizational professionals. Some companies manage things very well, others have their problems. This article will not provide you with a silver bullet for business & IT alignment, but provides some practical directions for establishing a business driven collaboration.

Basics

Although many approaches towards collaboration have been defined, some formal and others more informal, none of them seems to be that successful to become a general practice. All have advantages and disadvantages, making them work in some of the companies, but not in all.

The quality of the collaboration often depends on

  • The way the different parties understand each other
  • The way all parties succeed in managing each other’s expectations

A key driver for many companies is increasing business value of the internal processes. This implicates an increased attention to the efficiency of the internal business / IT collaboration model. The following paragraphs provide how business processes can be a valuable asset in improving the efficiency of the business / IT collaboration.

Common Understanding

One of the key elements lying at the base of collaboration is mutual understanding. If the different parties that are required to work together are not in line it is very hard to achieve a successful collaboration. In the case of business and IT, the presence of a ubiquitous language between business and IT is a mandatory precondition enabling collaboration between both parties.

Although this common understanding seems easy at first sight, it is often the first thing where things start to go wrong. Having a shared communication language is a good start, but insufficient. Business people and IT people have different backgrounds. They think different, and use words and statements that do not necessarily mean the same thing. An example: if a business user wants to be able to enter a new sales order very fast, is he then talking about the way the offer should be entered in an automated system, or is he/she talking about the response time of the system once he clicks the OK button of the order entry screen? He is talking about performance, but the perception of performance varies depending on the party and the context.

In the last years, many business domains have started an approach to model and optimize their operations. These initiatives (often referred to as BPM, BPO, BPI) take a look at the way the business operates, model this way of operation, and do some form of analysis and improvement on the operations. Where successful, it established a shared and commonly understood language between the different business domains of a company. A shared language that includes not only the behavioural aspect of the business (who does things, and how it is done), but also the information aspect (what is a sales order, what is a customer, how do they relate, …) and the business rules that apply to the processes and information (e.g. when a customer can place an order, how to calculate discounts, …).

If this shared language in the business is present, it will benefit your company if you manage to port it all over your organization, including the IT department.

In all organizations where IT is not the core business, IT has a support role. It merely supports the business in doing what results in company profit. The quality of this support will therefore depend on the way IT manages in understanding the operations of the business. From this point of view, it is very hard for IT to impose an IT language (such as UML, Use Cases, etc) to the business as the language to use towards IT.

However, introducing business processes in an IT department as a valuable asset they can work with, is not as hard as you may think. Most IT departments do model the behaviour aspect, the information aspect, and the business rules, when it comes to modelling business requirements for automation projects. Providing them with well modelled business processes, will majorly facilitate and speed up the analysis work they have to do anyway.

Figure 1

Figure 1 - Business/IT Process Model

Expectation Management

A second pillar of collaboration is the management of mutual expectations. These expectations can be very wide, but in essence they will cover the answers to these questions:

  • Who will deliver what?
  • By when?
  • How will this be delivered (format, quality)?
  • How will acceptance of the delivery be done?
  • How will intermediate communication be arranged?

The basics on how to make this work (process aspect) are handled in every book or training on (project) management. The process needs to work with a commonly understood baseline serving as content and context for the mutual communication.

Again, the business process model can serve as a reference base for managing expectations. They offer an understandable framework that can be used by both business and IT to pinpoint highlights, problems, attention points, but also to report on the progress of automation, report & communication of service interruptions, etc. Reporting on service levels or service interruptions based upon the business process model will improve the readability of the service report at business side significantly.

When a business process model is used as reference base, imho, the importance of the implementation methodology also diminishes. Evangelists often promote certain methodologies such as agile to be the way IT can prove business value. However, with a proper process model, the business has a clear overall view on what they want to realize and where the important points are. Whether a waterfall, iterative or agile methodology is used to make this happen, it is just a matter of delivering what is defined before, in a timeframe acceptable for the (business) customer.

How to Measure Enterprise Information Management Progress

Posted on by

Introduction

Increasingly, companies are embarking on a comprehensive enterprise information management program to address the growing demands on data coming from regulators, lawmakers and internal business executives. The goals of these programs include higher data quality, more transparency and control, faster access to information, and better insight into internal operations and customers. Compounding the task is the growing volume of data and the increasing knowledge required to handle the sophisticated data technologies.

While these demands can be handled separately, the best companies are realizing the same customer, product and financial data will likely be involved in multiple projects with conflicting schedules and different priorities. Individual data management programs with unique tools, processes and people are also expensive. Each project can require the involvement of the same key subject matter experts, busy people with specialized knowledge of the data and the processes used to create it.

Hence, the business value of an EIM program is the coordination, prioritization and implementation of a broad set of business and IT initiatives that plan and manage critical data holistically and efficiently across the company. A sound EIM program has the following components:

Data strategy: The company’s vision and goals for the data environment are best represented by a comprehensive data strategy. The strategy includes the technical and business direction for the critical data of the company. Because it is aligned with the company’s business goals, every change to corporate strategy requires that EIM be re-evaluated.

Enterprise governance: Governing data requires data definitions, standards, policies and controls. Included in governance are the various forums for decision-making as well as the responsible roles and the people accountable for the data programs.

Metrics/controls: Agreed-upon goals to be achieved by the EIM program are measured to ensure success.

Data quality: Programs that continuously measure and improve data quality dimensions, such as accuracy, validity, completeness, timeliness and consistency, demonstrate the value of the EIM program.

Skills: Hiring and training skilled information management professionals, in both IT and the business, to carry out the data initiatives is foundational to enterprise governance.

Enterprise data services: Enterprise data services are common tools and methodologies available to business and IT users of data and encapsulate best practices, facilitate reuse and contain costs. Examples of these services include metadata services, search/create/delete processes, ad hoc reports and data mart development. An often-overlooked set of services is the internal communication forums necessary to keep employees informed on the EIM program.

Trusted data sources: High quality, certified, common data sources are to be used across the company, including master data and the enterprise data warehouse.

An EIM program is broad by its very nature. EIM is a collection of multiphase, multiyear initiatives where responsibilities, processes and technology help create change. Core funding and a dedicated team are necessary to implement the components of the program and manage its progress.

An EIM Scorecard

How should progress be measured and communicated to senior management and to those who are funding the data programs? An EIM scorecard is one solution.

Similar to a balanced scorecard with key performance indicators, an EIM scorecard is implemented annually to measure progress against the EIM strategy and its various components. Once an overall EIM scorecard is established, individual scorecards can be developed outlining the contribution of various groups to the year-end metrics. A scorecard can be created for a local department, function or project that ties to the overall year-end enterprise metrics. If your organization has business data stewards, then develop scorecards at a business data steward level. A scorecard is also an effective technique for measuring the business data steward’s effectiveness.

Scorecard Metrics

As in the balanced scorecard KPI project, selecting the right metrics is critical. Determining the appropriate targets requires collaboration across the various owners of the metrics and the EIM program owner. Metrics should be easy to understand and reasonably easy to track. EIM scorecard metrics can be defined in the following categories.

1. Data infrastructure metrics measure the progress toward the technical data strategy vision. Because most companies have legacy duplicate data that drives data quality issues, data integration issues and costs, reducing these data stores and using corporate-approved trusted data is an indicator of progress. Additionally, target to reduce the total cost of the hardware, software and resources of the data infrastructure of the company to improve utilization and efficiency.

2. Data control metrics define new data standards, policies and processes that are necessary to manage data effectively. When new controls are defined, affected departments must comply in a certain time frame with supporting plans. Data control metrics measure compliance plans as well as any compliance testing results. The completeness of the enterprise metadata repository can also be measured in this category. All important data stores should have an entry in the repository with minimum information established by the EIM governance program.

3. The organization maturity metric measures the progression in training, skill development and role staffing. Any EIM strategy necessitates new skills and responsibilities in data management. Consider using one of the industry information management maturity tools to baseline the current data capabilities of the company and establish an annual improvement plan. The maturity tool can be administered internally or through a consulting company and includes a survey of internal stakeholders.

4. Issue management, such as logging data issues consistently across the company and addressing the high impact issues, is a critical barometer for management. Data issues that arise from internal audits, security testing or operational incidents are of special concern to the company and should be monitored via the scorecard. Logging issues in a consistent fashion also allows visibility into trends and the ability to identify hot spots to be improved on an annual basis.

5. Data quality improvement is a fundamental component of an EIM strategy. During the first year, the company would most likely baseline the dimensions of quality that need improvement. In subsequent years, projects are funded and more dimensions of data quality can be slated for improvement. This metric measures the year-end improvement plans against a set target. If possible, create an aggregate score of data quality for the firm, because too many metrics are often confusing.

6. Financial/cost improvements are at the heart of a scorecard. Clearly, no scorecard is complete without a set of financial or cost metrics that validate a solid ROI. Tracking individual project costs as well the overall business case for EIM would be included in this metric.

Each metric category has an assigned owner. The owner is the person or organization in the best position to affect change. The owner is accountable for establishing the baseline metrics as well as the year-end improvement targets and plans. The EIM program manager drives and owns the scorecard planning and reporting process. Creating quarterly or monthly interim metrics, where possible, provides management with early warning signs if the metrics go off track and provides an opportunity for remediation. It is highly recommended to automate the collection of the metrics, especially if interim metrics are necessary.

Communicating the progress of data initiatives to business leaders and executives is challenging and requires a clear and conciseformat. The EIM scorecard is emerging as an effective tracking formatthatprovide aconsistent mechanism to show yearly progress and communicate results.

—

This article was originally written by Mariah C. Villar.

Biography

Maria C. Villar is managing partner at Business Data Leadership. Maria Villar is an IT professional with more than 25 years of experience in IT, technology re-engineering and enterprise data management. She has held senior executive positions in both the technology and financial sector that included responsibilities for data quality, governance, architecture and database technology solutions. She built the first company-wide Enterprise Business Information Center of Excellence at IBM. The COE was recognized externally by for best practices in data governance and business intelligence applications. Villar has been recognized in Hispanic Business Magazine as one of the Top 100 Influential Hispanics and received the Distinguished Hispanic IT Executive award from Hispanic Engineer National Achievement Awards Conference.

Combining Lean Six Sigma and SOA/BPM

Posted on by

Reducing Operating Costs

Today the pressure is on the CIO and the IT organization to identify, enable, and create new business opportunities while dramatically reducing operating costs. In virtually every industry, aggressive, more technologically agile competitors are now offering new products and services faster or are executing processes more efficiently, to win customers, market share, and profit.

Thankfully, advances in technology and technical standards, specifically SOAs, are now allowing IT budgets to be reclaimed and the organization to be repositioned. New technical tools and capabilities complement traditional BPM methods and even unlock existing application functionality to greatly accelerate process improvement and innovation.

Leading firms are using BPM technologies to accomplish the following tasks:

  • Choreograph human and system interactions
  • Provide real-time visibility into key performance indicators (KPIs)
  • Manage escalations in the event of failure or missed targets
  • Provide the foundation for continued process improvement and optimization

However, on their own SOA/BPM do not address waste management or efficiency considerations. This is where Lean Six Sigma can help.

Step Back – Definitions & Terms

Lean Six Sigma (LSS) produces real results in difficult economic times by uncovering process waste, reducing non-value adding activity, and increasing productivity. The benefits are even felt in IT. According to the consulting firm McKinsey & Company, “companies can reduce application development and maintenance costs by up to 40%.” That application development productivity can be improved “by up to 50%” by applying LSS techniques, freeing budget for needed investments. 

Business process management (BPM) and service-oriented architectures(SOAs) combine with LSS to accelerate improvements and results. At the same time, they increase organizational flexibility and technology enabled responsiveness.

Many successful companies have found that the linkages are clear. Early adopters who have worked their way past cultural and organizational barriers are seeing impressive performance and financial results: 

  • Improved responsiveness to market challenges and changes through aligned and  market and tuning processes to meet the specific needs of key market segments
  • Improved ability to innovate and achieve strategic differentiation by driving change into the and respond to problems by using real-time data, automated alerts, and planned escalation
  • Reduced process costs through automation and an improved ability to monitor, detect,higher levels of component reuse
  • Significantly lower technical implementation costs through shared process models and improved ability to gain feedback and buy-in prior to coding
  • Lower analysis costs and reduced risk through process simulation capabilities and an improved ability to gain feedback and buy-in prior to coding

Recommendations

Lean Six Sigma (LSS) and business process management have much in common. Both methodologies use iterative improvement and design techniques to deliver financial and performance benefits through better managed and optimized processes.  

By combining key concepts from LSS with the capabilities of BPM (including process modeling and analysis, automation, and executive dashboards that deliver real-time performance metrics to process consumers), a company can ensure that its people are focused on the most meaningful value-added work. SOAs add increased flexibility so that processes can be quickly assembled from reusable Lego-type building blocks of technical functionality.

Companies that successfully bring together LSS, BPM, and SOA initiatives will realize a competitive advantage.

To fully understand the linkages between BPM, SOA, and LSS, and fully realize the benefits of these linkages, it is important to establish definitions and list key concepts for each initiative.

Conclusion

Process improvement experts are uniquely positioned to play a key role in this transformation as they are able to leverage their business and technical knowledge in combination with the tools and techniques of Lean Six Sigma.

Take Aways

  • Understand the basics of Lean Six Sigma and how BPM and SOA support the Lean Six Sigma methodology
  • Understand how to use data to select the right improvement project
  • Understand how Business Analysts can play a role in accelerating results
  • Consider embedding Lean Six methodology into your SOA/BPM strategy as part of your overall Enterprise Architecture

The rewards can be great, especially for those who take action now.

The Human Side of SOA – Part 2

Posted on by

All organizations have both short term and long-term goals. For most businesses, IT is no longer viewed as a strategic differentiator or even as a strategic enabler. It has become “part of the scenery” at best and, at worst, a hindrance.

The powerful combination of SOA and BPM has the potential to return IT to its former position as an agent for strategic advantage. The optimal value of SOA then is to support initiatives that are aligned with corporate strategy, especially those that focus on a move to exploit BPM. 

To this end, many organizations are following the advice of industry analysts to create an SOA Competency Center (SOA CC) that acts as a shared services group to oversee the transition to an Integrated Services Environment (ISE). 

The SOA CC ensures that an organization not only adopts the principles of SOA but also makes sure that it is adopted correctly and with the least disruption to the IT organization while supporting business users. This team must  comprise  members across the organization, from both IT and business. 

Traditionally, application deployments were stove-piped or functionally oriented in design. A department had a business need for an application with a specific set of functionalities, and the IT organization would build or buy the application, and then install, configure and maintain it. This process continued across multiple applications and departments. Each time the data and business logic were only available to that application and user community.

For example, the human resources department might use an HR vendor application, the sales and marketing department might use a CRM vendor system and the customer support group might use its own custom application. 

The move to an ISE is, at least in part, an evolution from a technology focus to a business focus, from a functional or departmental orientation to a process-orientation.

Integration moves away from the technology focus of subroutines, methods and components to business components that are focused on the discreet and granular events that are part of the business process.

By moving to ever higher levels of abstraction, IT’s deliverables achieve closer alignment with the artifacts of business modeling and begin to close the gulf of understanding between these two organisations that, in truth, rely on each other for their continued existence. 

The essence of the ISE and its primary consequence is increased business agility which, like virtue, can be said to be its own reward.

Projects must now be approached with an eye to the future and, more importantly, the re-use of the services created by that application. The company, as well as the project, needs to be aligned to corporate directions. 

The move to an ISE is a journey and, like any worthwhile journey, is not completed in a day and is not without costs.

The journey to an ISE rewards bold strokes, requires executive commitment and demands concerted effort in pursuit of a vision.

Ultimately, however, the success or failure of the transition depends on the people who undertake the journey, and it is the human side of SOA that will make or break the project.

The Human Side of SOA – Part 1

Posted on by

Application architectures have evolved greatly over the last 30 years of computing. They’ve shifted back and forth from proprietary character-mode terminals with centralised processing to client-server applications with distributed processing. Then, they shifted to the centralised hosting of applications but this time with open standards-based, web-delivered front-ends.  Each of these trends included a variety of methods to connect disparate systems—many proprietary, some without any re-usable characteristics and all typically requiring the developers, operators and maintainers to learn a new set of skills and the organisation to put new processes in place. These upheavals invariably created friction and frustration for the individuals and the organisation involved.

Enter the Service-Oriented Architecture (SOA). Not owned by any one vendor or organization, it is logically and physically a loosely connected set of principles and technologies that collectively constitutes the next, possibly the last, major generation of application deployment architecture.

The ‘human side’ of SOA ensures that planning, politics and personnel issues do not derail otherwise carefully designed SOA technology initiatives.

SOA changes the way applications are designed, developed, deployed and maintained. Application architectures that were once “built to last” are now explicitly “built to change.”

A SOA offers true technical benefits. Yet a successful transition to SOA requires not just technical change—but organizational change as well. If managed properly, this organizational change can further foster the growth, adoption and success of an SOA initiative. However, if not managed properly, it can cause disruption and organizational conflict.

Greatly generalized, there are two groups involved in any application: the business users and the IT group.

In a traditional application- development environment, interaction between these groups is limited to the times when there is either a new application to be developed or a problem with an existing application.

Interaction occurs primarily when the stakes are high and, therefore, often in an emotionally loaded environment. By breaking down the delivery of application functionality into discrete chunks or services, the two camps can lower the pressure, lower the stakes and collaborate more effectively.

The consequences of changing the level of granularity at which IT and business users interact is both subtle and profound. By concentrating on (relatively) simple business functions, IT can concentrate on automating tasks that remain relatively stable year-to-year.

In a world of globalised businesses, the biggest source of competitive advantage is found in business process innovation. Consequently, the parts of a business that change most rapidly and completely are the highest-level, most strategic business processes. In the traditional model, these business processes are implicitly captured in people’s heads or in hundreds of lines of monolithic application code. In the business world enabled by SOA, these business processes are instead moved into explicit, model driven Business Process Management (BPM) tools under the control of business analysts, where they can be changed and reconfigured at the click of a mouse.

If BPM is the way to enable business agility, SOA is the way to provide the IT agility that goes along with it. So, beyond the changes that occur in the way development teams and business users interact, SOA and BPM have the potential to change the way the entire organization operates. For this reason, the success of any SOA journey must be aligned to the corporate goals and vision and requires commitment and buy-in from the highest levels in the organization. Truly, the impact of SOA is both subtle and profound.

All organizations have both short term and long-term goals. For most businesses, IT is no longer viewed as a strategic differentiator or even as a strategic enabler. It has become “part of the scenery” at best and, at worst, a hindrance. The powerful combination of SOA and BPM has the potential to return IT to its former position as an agent for strategic advantage. The optimal value of SOA then is to support initiatives that are aligned with corporate strategy, especially those that focus on a move to exploit BPM.

What Makes a Good SOA Project?

Posted on by
I was recently approached by Project Managers who asked several questions about SOA.
 
This got me thinking and I decided to respond to their questions by sharing an article written in July 2008 by a colleague of mine (Technical Services Director from Progress Software) which may help.
 
The original article is available here.
—
Have you ever heard of this question, or something similar: “What is a typical or good SOA project”?

Let us examine the whole idea of and confusion around SOA projects in more detail.

First, let us consider what SOA is.
 
SOA is a conceptual architecture. It is not a product. For that reason, SOA is often misunderstood because it is not something that you can touch and click.

Also, every vendor’s SOA products and implementations are different. So no two vendors can agree on what is the best SOA implementation.

As if this is not complex enough, different vendors will stress certain features and functionalities to their advantage. Some stress the usability advantage. Other talks about a complete product stack while others discuss standards support, performance, or continuous availability as key advantages.

No wonder to the end user, SOA can seem like the latest 3 letter acronym that vendors are using to make money.

However, the reality is not that grim.

There have been plenty of SOA success stories, especially in North America and Europe, from every vendor. The difference between these regions and Asia is that SOA adoption occurred earlier and therefore organizations have gone through the learning phase of utilizing SOA and are now starting to see the SOA initiative paying off.

The other difference is the IT infrastructure build out in these regions have occurred much earlier so organizations can focus much more on SOA than on both infrastructure and SOA.

Also, SOA has clearly replaced EAI as the technology of choice. You can tell by looking at all of the traditional EAI vendors. They all have a SOA story and no one is talking about EAI anymore.

Asian organizations, which are behind in SOA adoption, should look past the confusion and leverage SOA to their advantage.

Organizations that are new to SOA can learn from the mistakes of the early adopters by focusing on the following:

1. Adopt SOA soon if you have not already. 

 
Despite the confusion, SOA offers many advantages like service reusability and service abstraction. In fact, SOA closely resemble what happens in real life. For example, when you use a service like stock trading, whether you call a broker or do it online, you are not aware of the complexity that goes on behind the scenes, nor should you have to. That is what SOA is about! At every step of the way, what the service does to achieve its objective is hidden from the service user. It translate to a much more flexible and agile infrastructure, which means you can add services or change your business process much faster to suit your business needs (i.e. business agility). Agility is a powerful business advantage.

2. Find the vendor that matches your needs. 

 
Every platform has its strong selling points. The question is not which vendor has the best products. Rather, it is which vendor has the right products for you. For example, if your enterprise is highly distributed or your business needs to be available 24×7, then a highly scalable, distributed, and available product is what you need. Having a sexy GUI may not be the most critical thing.

3. Most importantly, focus on the business objectives, not the technology.

 
The mistake I see organizations make is deciding on an ambitious SOA project or to SOA enable everything when the infrastructure is being revamped.

Many times the SOA project is part of a bigger infrastructure project so people are dealing with a lot of moving parts at the same time. When you have that many moving parts, it is even more important to focus on the business objectives instead of the technology: objectives such as business integration, factory automation, CRM, straight through processing, etc. There are many reasons for this.

Doing SOA for the sake of having the latest technology will get you no where fast. If you cannot show results, the best technology will get shelved eventually.

With every technology or platform, there is a learning curve for the organization. While it is the right thing to have a clear picture of the ultimate goal, you need to start taking small steps to get over the initial learning curve.

It takes a journey to reach certain level of SOA maturity. It is difficult to go from no SOA to highly optimized SOA infrastructure in one step. Organizations need to take manageable steps to reach such maturity.

Organizations that have tried SOA but have failed should ask a few questions:

  1. Is the project too ambitious?
  2. Is there a clear business driver? Is there management buy-in?
  3. Can the benefits be shown easily?
  4. Did I pick the right platform for my business?
  5. Answering these questions can help you find out where the problem is and regroup for the next SOA initiative.

So, this goes back to my original question and the answer is:

  • A good SOA project is a project that has a proper focus and clearly defined, achievable goals.
  • Your objective is integration, factory automation, BPM, etc. SOA is just the means to achieve these objectives.