Over the past few years, I've written a number of times on the use of business rules management systems (BRMSs) for implementing automated decision making applications. One particular area in which I see BRMSs as having a major impact on organizations' BI and decision support efforts is for enterprise decision management (EDM). Just to make sure we're all on the same page, EDM refers to the application of BRMSs -- sometimes in conjunction with analytic models -- to automate and improve operational decisions across the organization.

My new smart, stylish, cool PDA is a pain in the neck to actually use. There are so many features embedded in so many more -- these people have perfected hierarchical menus to everywhere -- that I find it nearly impossible to optimize its performance. There are also way too many decisions for me to make: do I really need 50 ring/vibrate combinations (not to mention the six-gazillion I can download)?

I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue.

With disaster recovery, 9/11, the war on terror, Sarbanes-Oxley, OMB 300, and a host of other influences, there are very few businesses that have escaped the risk experience. Virtually to a one, businesses are taking on the mantle of risk managers in a forceful, overt fashion. It is not universally because they have seen the error of their ways and suddenly recognize that risk management is a practice that adds value to their shareholders.

I was recently rereading one of my earliest e-mail Advisors from this Agile Project Management Practice (it was actually e-Project management then). The Advisor was about why this different way of managing projects was so important. After reading it, I decided it was time to revisit and update that issue.

In this Advisor, I would like to address the "people" component of getting your organization ready for smart sourcing, pointing out specific situations I have observed in my recent engagements with large and medium business clients. My reasons behind starting with the "people" component are twofold.

There's been a lot of activity in the past few months around SOA standards. For example:

August -- Open SOA Collaboration group is formed to advance SCA and SDO October -- OASIS Reference Model for SOA approved December -- The Object Management Group (OMG) begins work on UML Profile and Metamodel for Services

We've discussed SCA, SDO, Open SOA, and OASIS in previous Advisors this year. This week, I'll turn my attention to the UML Profile.

Senior leadership is often interested in identifying estimated costs before they approve any business-IT alignment or related projects. In some cases, the exercise of investigating the costs involve rigorous and meticulous due diligence as well as arduous cost/benefits analyses. In other cases, as assigned teams, we have used prior experience, calculated guesswork, and a combination of high-level estimation of the tasks involved to come up with the numbers.

by Martin Bauer

To think that because you employ an agile methodology you don't need to bother with requirements is simply wrong. Regardless of what methodology you choose for development, you need to know what it is you're building before you start building. To do otherwise is asking for trouble.

At the heart of attaining strategic alignment is identifying and pursuing those initiatives, projects, and programs that best support or enable the organization's goals and objectives.

As organizations carry out their business performance management initiatives, they are increasingly finding it necessary to provide their metrics, scorecards, and other analytics with access to current data from operational systems. The trouble is, the quality of this real-time operational data is suspect. This is because operational data sources rarely go through the rigorous cleansing processes routinely applied to sourced data before it is loaded into the organization's traditional (i.e., ETL-based) data warehouses and data marts.

In preparing for battle I have always found that plans are useless, but planning is indispensable.

-- General Dwight D. Eisenhower

I am fascinated by the continued conversations about EA's return on investment. They are especially exciting when we're actually able to conjure up tangible cost-saving projections to justify our investment in EA.

A friend of mine was discussing a large custom system that his organization was in the process of acquiring. "The vendor is recommending that we use a code-generator that they have developed to handle the complex stuff in a Java environment. I wonder whether this is going to work out any differently than the CASE stuff that we did in the late 1980s and early 1990s?"

"Why do you think the vendor is going this way?" I asked.

In my last Advisor (Collaborative Leadership Basics, Part 5: Why Project Teams Are Easier to Build Than Management Teams, 9 November 2006), I told you that project teams are the most straight-forward teams in which to develop high-performance dynamics because they fit the classic laboratory definition of a team.

One of the biggest information security decisionmaking challenges is finding economic value data that makes an ROI calculation for a security investment useful. Unfortunately, no magic bullet exists to resolve the problem, but a couple of stand-in approaches to the exploration of value might help.

Any manager knows that demonstrating the ROI of information security products is problematic at best. One of the biggest challenges is coming up with baseline data against which to measure a performance improvement and therefore value.

Strategic IS alignment refers to alignment between business and IS strategies, but the IS strategy is sometimes viewed in a narrow fashion, including only the role of the IS function (i.e., what does it aim to do?). I recommend a broader view of alignment, incorporating not simply the role of the IS function, but also the structure of the IS function (i.e., how IS activities are organized within the organization) and the sourcing of the IS function (i.e., which IS activities should be performed within the organization).

In my last two Advisors in this series (please see the sidebar) "Doing SOA Right Today, Part 1: Making Sure We''re on the Right Track" 27 September 2006 and "Doing SOA Right Today, Part 2: Resolving the Initiative Planning Challenges," 18 October 2006)

collaboration = innovation

To work collaboratively, we need to release these inhibitions to innovation:

In my previous Advisor in this series ("Getting the Business and IT Aligned, Part 1: Myths, Mysteries, and Realities," November 29, 2006), I shared a number of myths, mysteries, and realities for business-IT alignment in the fields of enterprise integration and business process transformation. I believe that business-IT alignment initiatives are not "one off" initiatives that happen in isolation, detached from other enterprise-level initiatives.

There seems to be a bit of confusion within the agile community about the concept of self-organization. To some it seems to be a euphemism for anarchy and an excuse to rail against management in general and project management in particular. I think this "anti-management" faction helps critics relegate agile to a "small-project, fringe" movement, which is unfortunate. Self-organizing isn't about anarchy or lack of leadership, it's about empowerment (or in the old school, delegation) and style of leadership.

BI leader Business Objects has bought software-as-a-service (SaaS) platform and on-demand CRM applications provider Nsite, Inc., for an undisclosed amount. Nsite offers a Web services platform and a set of on-demand CRM applications targeted at small and mid-size organizations seeking to add sales process automation to their CRM systems.

Mad cow disease, bird flu, airplane accidents, E. coli outbreaks, and shark attacks. I don't often get the chance to read Time magazine, but a cover story entitled, "Things That We Often Worry About (But Really Shouldn't)" caught my eye this week at an airport magazine stand. I was on my way to brief a CEO and his board of directors, and a topic for discussion was the things that people worry about when outsourcing.

In recent years, application developers have pioneered techniques that enable them to work in an evolutionary (iterative and incremental) manner, and now we're going one step further with agile methods that are also highly collaborative. Unfortunately, many data professionals are still mired in the traditional, serial approaches of the late 1970s and 1980s. As a result, they're discovering that they need to play catch-up if they're to remain relevant within the new environment.

"What did you know, and when did you know it?"

That query was the signature phrase from the Watergate hearings some 30 years ago in the US, which was looking into illegal activities conducted by the Nixon Whitehouse. It was resurrected during the recent HP boardroom leak flap about who knew what when regarding HP investigators illegally pre-texting corporate board members' and reporters' identities to uncover personal information about them.

Choosing the right offshore outsourcing vendor is certainly as much art as science, since the decision can turn on a number of quantitative as well as qualitative criteria. The first step in building a vendor selection framework must begin with an understanding of the overall nature of the relationship. Once this is established, a number of specific criteria emerge that can guide the selecting organization.