The ROI of Software-As-A-Service
|Sponsored by: SAP AG|
The ROI of Software-As-A-Service
|Sponsored by: SAP AG|
This is a topic that is of key interest to me in my role as an Enterprise Architect and IT Strategist.
As any architect will attest, governance is not so much a question of ‘why,’ but rather about ‘how’ and ‘when.’ More specifically, conversations and debates usually focus on how much governance is really necessary, as well as when and where to apply it.
Presently, I’m serving as the Enterprise Architect for Aer Lingus (Dublin, Ireland) and tasked with introducing IT Governance and the role of the Technical Design Authority (TDA) with a view of installing quality assurance disciplines to improve Business/IT alignment. I am also keen to ensure that IT has the correct controls and structures in place to avoid being “pushed around” by the Business.
Governance is not a new topic by any means. In this day and age, where end-users are fast becoming used to more responsive, agile and scalable IT solutions, governance is required to ensure that “demand and supply” between Business and IT are managed respectfully and properly.
Read on …
Why Governance? And Why Now?
By Ron Karas , 08/05/2010
Now, three initiatives are bringing a lot of these conversations to the forefront: cloud computing, SOA and mainframe modernization. There are similarities in the way governance is approached in each of these categories. Each is intended to break down silos, protect and preserve the integrity of information, and provide IT with more agility to create business value.
As more applications and services are exposed and potentially proliferate throughout the Web and across composite applications and services, the greater the risk associated with access and reuse of these technology assets. This gap will continue to widen as more products and services are introduced and integrated. As the infrastructure continues to evolve, there will be a demand for improved transparency due to the higher likelihood of policy violations and coding errors.
Yet, governing those assets as they evolve with the infrastructure can be tricky in terms of responsibility and ownership. That’s because it’s hard to clearly define the boundaries of an application or service once its used by different teams. This becomes increasingly more complex once an application or service is tweaked to address a specific business need; more changes to the software increase the vulnerability of coding errors if governance is not appropriately applied.
Applying governance after the horse has left the barn can often be difficult and somewhat ineffective. In this context, governance is regarded as a tactical effort focused on tools and functions within the infrastructure, as opposed to a more strategic initiative designed to align technology with the company’s larger business goals.
There are several reasons, or excuses, as to why governance sometimes takes a back seat in the overall IT strategy. It usually takes a combination of culture and software development processes that view governance as the step to take when things go awry or to be applied to only the most critical applications and services. While governance may be a priority for certain departments and controls may be in place with regard to how much of an application or service is shared, inconsistent governance practices will eventually make themselves known in unexpected ways.
When to Start
The specifics of where and when to start with governance depends on the existing infrastructure, and its maturity and reach. The simple answer to where and when to apply governance is at the onset of an IT initiative. Lack of governance from the earliest stages has a cost. The cost of fixing software code after it’s been deployed can be from 30 to 200 times higher than if the issues were addressed as the code was being written.
In an ideal situation, governance is part of the planning and design phases and carried out throughout the software development life cycle. Unfortunately, going back in time and retracing steps is usually not an option, especially for larger organizations with multiple IT balls in the air. When new initiatives such as cloud or SOA are being mapped out, they present the opportunity to insert governance as part of the overall technology strategy.
But what if there isn’t an immediate and new opportunity to extend governance policies and practices beyond their initial scope? This brings up the question of allowing governance efforts to simply remain the same. Why fix it if it’s not broken? While a company may choose to keep its IT infrastructure status quo for many sound business and architectural reasons, the reality is that there will come a time when they’ll need to interact and exchange information with a partner, customer or other outside organizations who have exposed part of their infrastructure to the Web. To mitigate the associated risks and increase transparency will require more stringent governance by both parties.
Governance is most effective when introduced through the combination of culture and technology. This requires raising awareness of its relevance and importance to the organization in a manner that’s in step with the company culture and existing processes. Engaging developers, encouraging the sharing of best practices and creation of policies and attaching rewards are some ways to achieve this.
From a technology standpoint, the use of existing policies and best practices can accelerate governance efforts significantly reducing the hours required to create these tools from scratch. The concept of policies and best practices are usually not foreign to development teams. However, consistent enforcement in the form of a real governance initiative typically is. In fact, many of them are widely available from architects and developers who realize the value to the industry as whole by paying it forward.
Can there ever be too much governance? Yes – too much governance can be worse than too little governance if it hinders productivity. Start off with a more passive approach to governance in the early stages of development, notifying project teams of issues and their potential impact. As you move closer to production, you can take a more active approach, such as blocking users from checking in artifacts to the registry/repository unless they comply with established policies.
An important point to keep in mind is when organizations are instituting governance for the first time it is a new effort and will require additional costs in the short term but ultimately will reduce overall development costs.
Making governance worthwhile requires a consistent approach to developing and deploying applications and services. It also means enforcing policies across different departments based on a common set of best practices, standards, policies, and patterns.
Finally, it stands to reason that if the services and applications are going to be distributed throughout the infrastructure, so should governance. This way, enterprises can put into place the policies and best practices that should be followed as the software continues to evolve and serve different parts of the organization whether it’s an SOA, cloud or any major IT architecture.
By Alan Earls , 12/16/2010
Editor’s Note: In Part I of this special report, technology journalist Alan Earls examines whether document-centric BPM is morphing into case management. Here, in Part II, he describes the power-and the complexity-of case management BPM.
Case management BPM –also sometimes known as dynamic BPM, or, in IBM parlance, advanced case management-has been getting lots of attention lately.
With its roots in document-centric BPM, case management BPM can be a natural evolutionary direction for some organizations. But with its much greater complexity and higher ambitions in terms of what it seeks to accomplish, it’s not for everyone.
One key driver for developing and adopting case management BPM: extremely high payroll costs for knowledge workers in developed countries, according to IDC analyst Maureen Fleming. Knowledge workers tend to work on lots of projects, with the concept of the “case” as an underlying core principal. As a result, organizations interested in understanding processes tied to this often highly unstructured work need to gain a better understanding of case management to better understand how to make their knowledge-centric work more efficient and systematic.
“Case management BPM is expensive from the larger vendors and relatively immature for lower-cost BPM suite vendors,” Fleming warns. Furthermore, there are often skills gaps on the professional services side that present their own set of challenges. “Depending on who you talk to, case management is either huge or just a subset of the BPM software market. In other words, there is a lot of variation in how vendors view this as an opportunity,” she notes.
Customers, of course, view it more in terms of the problem at hand. “Enterprises that view case management as a content-centric problem look for different types of solutions than companies that view this as a process problem,” Fleming says.
In her view, case management is inherently an integration-or a mashup-of multiple content and data types driven by requirements. While that concept is straightforward, getting there isn’t. “With a BPM suite, there is often a discovery phase that helps the process actors articulate linear workflow, but I’m not seeing the same level of sophistication for case management, which is highly process-centric but only partially linear,” she adds.
As with any application, Fleming notes, there are multiple potential pitfalls and risks. One is the possibility of adopting a system that is relatively inflexible, making it difficult to adjust to meet evolving needs. Another is underestimating integration requirements.
Still, Fleming says that IDC expects decision-centric BPM, including case management, to grow faster over the next few years than classical BPMS-based process applications, though from a smaller base. “In general, we believe decision-centric automation will grow faster than most types of applications and middleware over the next five years,” she says.
Automating the right tasks in the right way
ebizQ contributor James Taylor, a specialist in decision management and related areas, also focuses on the complexity of this flavor of BPM. “There was a convergence around the idea that some processes had complex data, multiple documents and lots of people involved,” says Taylor, who is CEO and principal consultant at Decision Management Solutions. “Some approaches are very technology-centric, focused on integration, and some were more focused on people.”
In other words, in its evolution, BPM had already shown that many processes had work activities that could be highly automated. However, those processes still sometimes had exceptions as well as tasks that did not lend themselves to an automated approach.
Now, advanced case management solutions (the term that Taylor prefers to use) can provide automation that prompts for human intervention when needed but then continues to automate for better efficiency. “For instance, you now see insurance companies automating the claims process and banks automating loan origination in a way that integrates straight through processing and complex case/exception management,” he explains.
“These kinds of systems monitor the process, apply rules and predictive analytics to make decisions and know when to escalate an issue for intervention,” he says. “The system does what it is good at and lets people do the things, like talking to other people, that they are good at in a seamless whole.”
By Alan Earls , 12/10/2010
Some application categories are short-lived. Capabilities change, business conditions morph and buzzwords fade away. But in the instance of what’s currently called (at least by some) document-centric BPM, there’s a remarkable degree of consistency between the old and the new.
According to Sandy Kemsley, an independent BPM consultant based in Toronto, its roots go back some 30 years.
In the early 1980s, new document-imaging and workflow approaches were emerging. “BPM was always part of document management, but then it started to become a separate discipline in the late 1990s,” Kemsley says.
Big analyst firms came in with new theories and terminology proliferated. Now there was human-centric BPM, integration-centric BPM and, of course, document-centric BPM.
Where does that leave decision-makers who are considering a document-centric solution–or living with one they already own? Kemsley says that despite being in a somewhat “muddled” state, document-centric functionality is a well-established winner. When it comes to systems that handle things like transactional documents, the value is clear: the ROI comes from reduced need for data re-entry and reduced head count. “That has been the case for the past 30 years and nothing has changed that,” she says.
What has changed is the emergence of additional flavors of BPM, especially case-management-centric BPM (sometimes known as dynamic BPM), which offers potential efficiencies for workers handling complex semi-structured or unstructured processes.
“A current challenge is to know your problem and then figure out how to map requirements into structured or unstructured workflow—and if it falls in between, you may need to do both,” says Kemsley. For example, she notes, an insurance claim may start off very structured and then quickly get into unstructured case management territory, where processes and solutions have to be invented or applied uniquely. It is still the same “case,” but having the right tools makes for better management.
Case management can also be thought of as a form of customer service, she says: “One person can now see everything that is being done and what stage everything is at.”
Document-centric BPM has revolutionized processes in many organizations and case management offers similar potential. “This kind of system means people don’t have to be at their desk, they can start to work at home or wherever,” Kemsley says.
Adds Gartner analyst Toby Bell: “If you are doing document-centric today, you should look to leverage that toward a case-management, human-driven approach in the future.”
When explaining what case-management-centric-BPM is and why organizations need it, Kemsley says simply: “You want to get away from people having notes about clients stuck to their monitors.” Elaborating on the difference between the two BPM flavors, Kemsley notes that document-centric BPM has focused mostly on enhancing repeatable, process-oriented activities, traditionally built around paper documents. In contrast, its offspring–case-management or “dynamic” BPM–links documents, people and all kinds of social media to enhance the messy process of addressing an insurance claim, a government benefits appeal or a legal case. “In situations of that type, when people are able to more effectively share and track information, it benefits the individual and the company gets benefits, too, so they can incentivize the individuals to participate,” she says.
A 2009 Forrester Wave report (“Dynamic Case Management – An Old Idea Catches New Fire”) contends that demand for case-based or “people-driven” BPM products is an outgrowth of the service sector’s adoption of many of the Lean and Six Sigma approaches long used in industry.
The result has been the gradual elimination of many tasks through automation, outsourcing or process improvements. Analyst Craig LeClair, who wrote the Forrest Wave report, uses an insurance industry claim as an example. “Scanning in claims documents and entering data into a claims system is where traditional [document-centric] BPM would coordinate activity among the submission, underwriting, policy creation, claims and customer service,” LeClair says. BPM would also traditionally extract metadata from core processes and make it available to better serve customers across all lines, he notes.
Exceptions to the rule
What’s left, increasingly, is “exception management” – handling the more complex tasks that can’t be fit into a preformed solution. In other words: case management. “Today’s knowledge workers have a greater variety of tasks to deal with and they aren’t locked down in one place, like the production workers traditionally served by document-centric BPM,” LeClair says. The tasks left over are more diverse and require a broader level of information support and even analytical support.
What the new processes look like might be “snippets of structured functionality” as well as social technology to get access to expertise. “Image capture and document management are still very important, but case-management capability is where the big, high-value developments are,” says LeClair.
If you’re considering a case-based BPM system, LeClair recommends thinking about it from a business-process vantage point. One key distinction between the document-centric BPM system you might currently have and a case-based system is that all “exceptions” are carefully scripted in document-based system, he says. In contrast, in the dynamic or case-based world, the business outcome becomes the driver. For that reason, “companies need to involve their business process analysts early,” LeClair says. “They should try to align desired business outcomes in their existing BPM system with the strategic goals of the organization, and then use that as the basis for moving forward to dynamic, case-based BPM.”
In his report, Le Clair notes that the rapid emergence of dynamic BPM may spur acquisitions among industry players and could bring in others, such as Oracle, which has relevant ECM and BPM assets. And, he warns, BPM pros need to keep in mind that case management needs to be considered as a “lean approach for automating processes,” but with much more control given to the “worker.” Indeed, he urges a “design for people” approach that incorporates Web 2.0 approaches.
And, he recommends: “Reengineer the process first, then pick the tool. Focusing on the tool too early is a huge pitfall.”
By Peter Schooff, Contributing Editor, ebizQ , 12/17/2010
In this Q & A, Peter Schooff speaks with ebizQ contributor Dr. Alexander Samarin about corporate BPM strategies. Samarin, chief enterprise architect of the African Development Bank, is author of “Improving Enterprise Business Process Management Systems” (Trafford Publishing, October 2009).
PS: Why should a company consider BPM?
AS: For me, BPM is three complementary things. First, there’s the BPM discipline, how to use processes to better manage an enterprise. Second, [there’s] BPM software [and] technology from many, many vendors. And third, [there’s the] architecture of a BPM enterprise system that is built to manage, to govern, execution of the processes within enterprises.
Together, they’re very powerful tools and [a] primary force to make an understandable, explicit and executable coordination between systems, employees, customers and partners. With such coordination, it becomes possible to monitor the dynamic of various indicators, values and risks, and it helps people for better decision-making. In addition, it helps with the evaluation of feasibility and impact of future changes.
PS: What are some problems that companies face when they go to BPM?
AS: Typical problems at first [involve questions about] “What is it?” A lot of efforts are spent to explain BPM. Usually within a company, there is a mixture of opinions from the Internet. So [building] a commonly agreed-upon understanding about BPM is a must.
Second: “What does it do for me?” [It’s necessary to explain] to everyone how BPM will address his or her concerns and how his or her current working practices will be changed for the better. Of course, it’s not necessary to talk to each of the thousand people within a company; instead, be prepared for talks with about 20 groups of people.
[A third question involves project size.] BPM projects usually start small, without a bigger view or understanding of how to grow. [I] recommend considering BPM as an enterprise-wide initiative from the very beginning.
The last typicalis: “How do we change it?” By definition, any BPM solution will be changed…So [my recommended] approach is to architect flexibility because many, many changes will be carried out.
PS: Is an enterprise architecture approach important for companies that are considering BPM?
AS: Yes, both enterprise architecture and BPM are enterprise-wide activities or programs, and you don’t want them to collide. At first look, they’re very different. Enterprise architecture is about [going from] this state to this state as a transition, and the typical lifespan is [measured in] years. BPM, on the contrary, is talking about continual improvements and a typical time span is weeks or months.
But the two may be very complementary and enrich each another. For example, enterprise architecture does a great job in describing the enterprise genotype, or full nomenclature, of enterprise artifacts. And there are many techniques to evaluate enterprise phenotype, a set of observable characteristics such as performance. But enterprise architecture cannot answer how enterprise genotype defines enterprise phenotype. From the BPM side, it’s very strong with executable models of relationships between artifacts. And in this way, it can form some kind of a bridge between enterprise genotype and enterprise phenotype.
Actually, your enterprise architecture team should be the best friend of your BPM initiative and vice-versa.
PS: Essentially we’re talking about processes that are human processes. So what is exactly the social aspect of BPM?
AS: English is not my mother language, so I [looked] at the different meanings of this word “social” and took some of those meanings.
First, [it is] affordable to everyone. BPM and new tools are now more affordable for small and medium enterprises and governments. Second, [it involves] public or common ownership. Right now, this is mainly organization of work and provisioning of convenient access to different artifacts, which is a common practice in modern BPM tool.
And the third meaning, which is the simplest, [involves] human-initiated interdependent relationships with others…Of course, that last meaning is the most interesting for clients of BPM.
PS: You touched on this in the first question, but to drill down a little bit more, exactly how does BPM help companies solve their problems?
AS: BPM mainly helps companies through managing the common understanding of work. One aspect [is] coordination. Coordination is externalized from people’s heads, applications, quality documents and habits in an understandable and explicit form. One of the forms is the well-known BPMN [Business Process Modeling Notation] diagrams.
Then this explicit coordination is used through the whole improvement lifecycle: plan or model, implement, do or execute, check or control, and act or optimize. In many enterprises, those phases are carried out by different roles and often different languages are used…And each time information is moved from one role to another, there are some translation errors, explicit coordination in BPM removes the source of those errors.
Then BPM helps people to express coordination the same way, so that different people within an enterprise are solving the same problems in very similar ways, thus improving reusability.
And finally, BPM makes your enterprise information more flexible because executable coordination serves as a way to assemble bigger services from smaller ones. So BPM helps companies to make some kind of breach, glue or guidance between strategy and execution.
PS: What do you see ahead for BPM?
AS: I can see that it should [include] better understanding among BPM experts, more practical standards, easy comparable business cases, more commonly agreed-upon knowledge, better interchange been tools from different vendors. We know that BPM is a vendor-driven market right now; I see it [becoming] more customer-driven in the year ahead.
This Q & A was excerpted from a recent ebizQ podcast. It has been edited for editorial style, clarity and length.