IT and Business Alignment Begins with Listening

By Robert Stone, Managing Consultant

A lot has been written about the topic of IT –business alignment. We see it in action at our clients all the time. Baseline even offers a course on the topic.  I’ve made certain observations about it in my client work over the years that I’d like to share in this blog post.

We find that business intelligence projects are often the optimum way for companies to achieve tighter IT-business alignment. That’s because IT - business alignment will succeed only if you’re solving a business problem.  IT should not show up at a meeting with business users and recite a laundry list of everything they can do.  They should also avoid discussions of technology or existing reports. Instead, they should ask the business what their problems are.  Stakeholders actually enjoy describing what is preventing them from achieving their strategic goals or, at an individual level, what is preventing them from being more productive in their daily work.  IT should listen to the concerns of the business stakeholders and then determine how they can help in an effective manner.   Successful projects will become more frequent because IT already knows the business problems in detail before the project ever begins.

photo by Orange_Beard

Alignment is really all about building a relationship of trust.  If you constantly help business find reasonable and effective solutions then they will trust you.  Trust is also doing what you say—much easier with a set of articulated business requirements in place—and this requires good data management and business intelligence capabilities.

Alignment is not about pitching the business on a new project, the latest BI tool, or the latest methodology. It’s about establishing rules of engagement that can only be followed after earning the stakeholders’ trust.

SOA and Enterprise Applications

By Adam White, Senior Consultant

It’s frustrating to see the consistent mistakes enterprise and solution architects make when implementing and supporting Service Oriented Architecture (SOA).  The most common one is co-opting functionality that comes with a packaged product as an enterprise solution.  

One example is using CRM workflow as enterprise workflow.  Most products nowadays  come packaged with workflow capabilities.  This means that events can trigger a process and that processes can interface outside of the application to activate other events. The first inclination of many enterprise architects is to utilize that functionality to support the enterprise-class business needs.  The problem is that the functionality that comes with the product is designed to support the product, not the overall enterprise. 

However, there are workflow products that support the entire enterprise. The easiest way to tell is by applying two trusted rules of thumb.  The first is by mapping your functional requirements.  You will see that by using this yardstick, product level functionality is different than enterprise level functionality.  And the second simple rule is if you replace your packaged application (say, your CRM application) do you also have to replace or rebuild your workflow?  The answer should be no.  If it’s yes, then you have incorrectly repurposed the product’s workflow functionality. 

This also occurs in the integration world.  Just because an ETL solution provides integration and can call a web service does not mean it’s the product to use for your core applications. After all, these are systems that support business operations, the systems that you use to process your day to day customer transactions.  In the end, it all comes down to fleshing out your requirements, and using the right tool for  the right job.