This blog covers the practical techniques, trials and tribulations associated with the transformation of IT systems from legacy technologies to systems using SOA and modern open systems. It also includes the occasional interlude with rants about technology in general.

Friday, June 18, 2010

The Relationship between Technology and the Line of Business

Perhaps you have noted by now that I have repeatedly suggested the importance of having a good and respectful relationship with your business group and that their involvement and support is essential to the success of a technology transformation program.

Without question, you should expect the business team to be the deeply involved during the early phases of the project. In the early stages you’ll need to work with the business partners to get the project approved (without their sponsorship, the project will simply not be approved), to define the detailed requirements, and to establish delivery commitments. Business should also be heavily involved during the later stages for purposes of project acceptance and delivery. Their role at that point will, by necessity, be slightly adversarial. After all, they are one of the key players in determining the quality and success of the deliverable.

The role of the business area during the execution phase of the project is not as clear. The various business groups involvement during the execution phase will depend upon a number of factors, ranging from the cultural style of your organization to the idiosyncrasies of the individuals in the business teams. Another variable is the type of project, the specific deliverable within the project, and how well or how badly the project is coming along. You may have a business team, perfectly happy to assume a “laissez-faire” attitude regarding IT as another form of “vendor”, and taking the position that they are your customer, to whom you will deliver the committed product or service. At the other extreme are those business groups that firmly believe the IT organization to be their butler; tasked to do their bidding. Then, of course there are a variety of attitudes in between these two extremes.

There are problems with the extreme views. Yes, if you are in a company that views technology as a commodity enabler, the perspective that technology is a “service” function might well apply. However, if you are in this type of company, you probably shouldn’t be involved in a transformation technology project to begin with. Let’s face it, a technology transformation project cannot truly succeed if there is a view of IT as simply a “vendor” or a “service-center” for the company.” The days when the business could strike IT for being late with “the monthly report,” or could set arbitrary deadlines for those “immediate changes to the way the discounts are computed”, and then have the IT folk limp away Quasimodo-like with a submissive, “Yes, master!” are over (I know, many business friends of mine would easily argue that those days never occurred!). There is only one way for the business and technology teams to interact with each other when confronted with a major project such as a transformative project: as partners . . . equal partners.

Establishing an equal partnership view between technology and business tends to be more controversial than it should. Oftentimes this view is opposed implicitly, or even overtly, by certain lines of business. You often hear, “The business is paying for this, and so it’s our prerogative to decide things.” Reality is that the business group is not the one paying for the project; the company is the one paying for it, through the business. Everyone has fiduciary responsibility for the well-being of the company; not just the line of business.

The fact is, having the technology team act as an “order-taker” is only feasible under certain scenarios, such as when delivering a stream of tactical initiatives, or when delivering basic support services to the business. The partnership- as-equals relationship is a better way to establish a decision making framework that will hopefully serve both respective governances. This type of relationship also demands shared responsibility and the ability of the technology team to understand business needs. For a trusting partnership to exist between business and technology, the technologists need to become acquainted with the business imperatives, while applying the knowledge and imagination needed to effectively leverage the emerging technology in ways that provide a clear competitive business advantage. Technology should endeavor to proactively identify business enabling approaches, and to socialize and communicate to business the universe of what is possible, so that the business leadership can enjoy a wider menu of options and be better armed in the priority-setting exercises that are sure to follow. Let’s not forget that, ultimately, to be deemed successful, technology must deliver a business benefit.

So, where is the line drawn in the decision making? First of all, I have never experienced even the most “hands-on” business team attempt to make detailed technology decisions when it comes to infrastructure choices. The types of router, firewall, hardware, or system management tools to use, for example, are decisions best left to the technology team. Alternatively, it is not a good idea for the technical team to debate with the business team as to the aesthetic, branding or usability aspects of a user interface. Render to Caesar the things which are Caesar's, and to technology the things which are technology’s. Seriously, you can have your technical staff express their preference, but there are certain decisions that should be made by the business team, as long as they don’t have a true direct or indirect impact on the complexity of the solution. For example, if the business team demands to use Flash for the interface, you can oblige, but don’t let them force development of business logic within the Flash scripts if it violates established architecture tenets.

A partnership relation between the technology and business teams entails a balance of the sphere of decision-making, mutual respect (at the very least, the team making the decision should listen to the other team), and ideally should achieve some degree of consensus on the overlapping areas of decision making. This is easier said than done when the impact of a decision spans both the technology and business areas. An example would be the choice of a solutions vendor, or even the decision on whether to develop a certain capability internally or to purchase it externally. Even if you have defined a tenet stating that you will only develop solutions that match your core competencies, there may still exist gray areas open for debate. For example, say you are selecting a campaign management vendor. Campaign management is an area that will typically have very high visibility for the marketing and sales business group, and rightfully so. The business will likely have a strong opinion regarding the tools to be used, based upon the analysis of functionality and the perceived friendliness of the interfaces. Technology, on the other hand, will want to evaluate the underlying architecture and standards used by the vendor, including the schemas used for customer data bases and the integration capabilities offered by the tool. Who decides in this case? The short answer is not “the one that screams the loudest.” Rather, this is a situation that calls for reasoned discussion and consensus building. You should always maintain the business arguments in the sphere of functionality. If your technical team is arguing for a different vendor or solution, you will need to validate if, in fact, the solution favored by the technical team meets the core business requirements (emphasis on “core”). In the end, this type of debate might have to be escalated in order to obtain resolution. However, even if it is determined that the business preferred option is the one to be followed, you should ensure that the minimum integration objectives can be met. In the case where the business is pushing for an external solution (e.g. A Microsoft based solution when your entire platform is Linux based, or a solution that relies on the vendor’s proprietary architecture, etc), you will be required to explain the reasons why you and your team find this type of solution unacceptable. If you are over-ruled, you should make sure to document the reasons for your team’s position and the expected impact the decision may have. In the end, this latter outcome rarely occurs. I believe that ninety percent of the time, a viable compromise can be reached.

The key aspect to remember is to engage the business as an equal partner; not as an order-taking entity, and to include them in the project as much as necessary; while clearly delineating who is responsible for what decisions. It’s not always easy to engage the business this way, I’ll admit, but the alternative of enduring a dysfunctional relation is would make the success of the project very doubtful.

IT Transformation with SOA

About Me

Israel has been recognized by Computerworld as one of their Premiere 100 IT honorees. Israel is a business and technology leader who has contributed the technology vision as key strategist and designer behind the enterprise technology roadmaps of large hospitality and travel companies. Israel has also have developed and deployed various mission-critical systems and in the process, he's been instrumental in creating and building effective and skilled development organizations.