Daan Rijsenbrij, donderdag, 12 november 2009
Gene Leganza provides research and advisory services that address the needs of enterprise architecture professionals. He focuses on helping clients implement a pragmatic approach to enterprise architecture that has clear value to business and IT leaders.
Gene came to Forrester through its acquisition of Giga Information Group. Prior to joining Giga, he was director of infrastructure architecture and capacity planning at John Hancock Financial Services in Boston. Previously, he held senior IT positions at First Data Corporation and Fidelity Investments and development and marketing management positions at leading software firms.
Daan: “Gene, you examined almost all important architecture subjects for more than 10 years including the relation between architecture and outsourcing.
It is very important that an architecture is feasible. Nowadays outsourcing looks like the most important way to realize an architecture.
Our readers like to learn form you how architecture can help to achieve a greater success in their outsourcing. So let’s start with some simple questions.”
Daan: “How do you define enterprise architecture and how do you explain that to your non-IT friends?”
Gene: “Believe it or not, even after doing this for 10 years, I hate having to define enterprise architecture. To describe it in one sentence requires going up to such a high level that it sounds impressive, but it’s hard to tell what it really means.
I tell my non-IT friends that it’s a fancy set of concepts that basically amount to planning the best way to use technology to achieve business goals.
I’d like a formal definition to de-emphasize the technology aspect and prioritize the business. How’s this: ‘Enterprise architecture is a set of planning and governance disciplines that enable innovative, effective, and efficient use of technology to achieve business goals’. Although, ask me again in about a month and it’ll come out a different way!”
Daan: “I shall not ask it again, but perhaps you could spend some more words in future about the definitions of architecture understandable for business people in your architecture blog: http://blogs.forrester.com/ea/gene_leganza.” Daan: “Some years ago I wrote an article in a Dutch Magazine entitled ‘Outsourcing without architecture is like driving a car without a safety belt’. To put it more firmly it is possible to outsource without a proper architecture study, but this is highly irresponsible. In case of an accident the damage will have a severe impact. Can you comment about that?”
Gene: “I think that’s an apt analogy. Giving up control of the architecture for any reason (including just not paying attention to it) introduces significant risk to any enterprise. It amazes me how many organizations just assume that outsourcing automatically means no control over architecture.”
Daan: “What kind of architects do you consider in the context of an outsourcing process? Which architects must be on the payroll of the outsourcer and which architects should be on the payroll of the external provider?”
Gene: “It depends on the type of outsourcing, of course. The infrastructure and operations service provider clearly needs to have every kind of technical architect. Any situation that includes application outsourcing requires the vendor to have a solution architect. The outsourcing customer can probably live without an infrastructure (technical) architect, but at least some of the enterprise and solution architects they have should have a good general grasp of infrastructure issues. But the outsourcing customer still needs enterprise, business, information, application (domain), and solution (project) architects.”
Daan: “How does one govern the supervision of the overall architecture. I mean the architecture of the outsourcer plus the corresponding architecture of the external provider? Is it wise to set up a shared architecture framework?”
Gene: “A ‘shared architecture framework’ would be a very smart thing, but it can be difficult to get an outsourcing vendor to be open to that. It’s best if you include a description of the process you are looking for in the contract, describing the roles you want to interact with, the roles you will bring to the table and specify the frequency of the meetings. The best way to think about it is to determine what you would like to happen in an internal scenario, and then describe it in formal terms to define the relationship with the provider.
When organizations go through an outsourcing process for the first time, they take a lot for granted and end up with major gaps in their vendor management capabilities. You need to think of the interactions you would want to have with internal IT on a daily, weekly, monthly basis and specify them in the contract. If you do this, you can include regular meetings with internal and vendor architects.”
Daan: “Does the same division of architecture expertise also hold for package suppliers like SAP and Oracle?
Do you think that a proper architecture in the case of a software package can really prevent a vendor lock-in? I mean of course an architectural lock-in, not a business lock-in.”
Gene: “Software providers will not need the infrastructure architects, although, as more vendors offer hosted SaaS versions, they will probably need them as well. But in a hosted application scenario, it’s unlikely a customer would have a discussion with their infrastructure architect – they are contracting for application services and the infrastructure tends to be in the background.”
Daan: “How about stuff from the cloud? Is it necessary to dust off your own architecture before you are going to apply Google Apps for instance?
And should you be aware of the implicit architecture of the things you get form the cloud?”
Gene: “You really can’t let all the hype about cloud offerings distort your judgment. It’s still architecture, and there are aspects of it that can be major benefits and there are aspects that are just inappropriate for some workloads. You shouldn’t oversimplify what ‘cloud’ means. Different SaaS offerings will share different components, and you can opt for hosted cloud offerings that are midway between public cloud offerings and internal cloud configurations. So for a particular workload (application or service) you have to lay out the characteristics of the various cloud possibilities, your requirements and the benefits and drawbacks of the various options. Just because it’s easy to go to the cloud for something doesn’t make it the right decision. Easy, fast, and cheap are all good things, but that’s not the whole picture.”
Daan: “Consultancy bureaus (such as TPI, EquaTerra or Quint Wellington Redwood) are often involved as mediator in outsourcing deals. Is it important that they bring in architecture knowledge? And on what areas?”
Gene: “My idea of an architect is one with superior technical knowledge, superior communication skills and the ability to understand various disparate points of view, so I’d say yes in general to that. The best architects are great mediators and the best mediators regarding anything IT-related are architect-level people. As to what areas, it really depends on the type of outsourcing arrangement – there are so many approaches. An enterprise architect would be needed, in many cases a technical and a solution or application architect as well.”
Daan: “Does it matter for the architecture of the outsourcer whether the outsourcer makes use of single sourcing or multiple sourcing? I mean with various independent external providers.”
Gene: “Yes and no. Almost any outsourcing deal will include multiple providers, whether it’s explicit in the contract or not, as a provider will be likely to use other providers. So it’s pretty much a given that you will have to engage in multiple sourcing. But that can either be a mess, with no one held accountable for problems, or it can be run smoothly. The key is that any service provider must be held responsible for anything they contract out to another provider. This starts with the internal IT department who may have outsourced their entire operation to an outside firm. The business should hold internal IT responsible for everything, and IT needs to be sure they can get their outsourcer to provide what the business needs; this cascades down through the vendors’ vendors. It’s all a matter of best practices in vendor management.”
Daan: “At what moments in the outsourcing process is it necessary to involve architects?
For this question I like to use the following outsourcing phases: decision-making about the possibilities/desirability of outsourcing, selection of the external providers (RfI, RfP, BAFO, Due Diligence), transition, transformation, delivery of services and the maintenance on those services, and maybe the termination or switch to another external provider?”
Gene: “I can’t think of a phase that could reasonably exclude architects. Early discussions should surface the important issues to consider regarding architecture. All the selection steps require architects’ attention. Transition and transformation could possibly demand less of an architect, but it’s easy to get blind-sided by an implementation that just seems to have worked out differently than planned, so some involvement to monitor progress is warranted. Delivery and maintenance of services is really like the architects’ involvement in normal IT operations. I can’t think of a business reason for termination that wouldn’t involve an architect, and of course a switch to another provider starts the whole process over again.”
Daan: “As an architect I consider at the transition and transformation an AS-IS and a To-BE architecture. Do you find that the external providers should play a role in the concretization of those architectures? Should they formulate a kind of project start architecture for the outsourcing process and how about the building permits?”
Gene: “Again, it depends on the specific arrangement. The outsourcing vendor has significant financial interest in the to-be infrastructure architecture. The outsourcing customer needs to understand the requirements of their own to-be business, information, and application architectures and the implications for their infrastructure architecture and then begin discussions with the vendor. As for the building permits, it really depends on who is doing the building. If development is outsourced, the development process has to accommodate the appropriate governance stages, which are typically spelled out in the contract. Building permit discussions would involve enterprise and application architects from the customer and the solution architects from the vendor.”
Daan: “The great fear of outsourcing I see among some of my clients is that from the legacy in their own enterprise they could end up in a rigid back office of a provider. Both situations have the same disastrous consequences that it is impossible to make rapid adaptations to changing market circumstances. Could you comment on this potential nightmare? And what can one do to prevent them?”
Gene: “This nightmare is a reality for many organizations. For some, an outsourced environment doesn’t make much difference – they would be under the tyranny of their inflexible legacy systems whether they are running them or someone else is. For others, the lack of control of an outsourced situation and the loss of internal expertise on the legacy system puts beneficial change further out of their reach. The only real prevention of getting locked into a legacy problem is to plan the application portfolio going forward and developing a roadmap for where you want to go. If you find you need to keep a key legacy system alive indefinitely but that you will need to integrate with it or modernize it’s user interface, make sure you have control over the application code. Outsourcing is not an on-off switch – there are many approaches and who hosts a legacy application is only one of many options. Maintain control, plan a way forward, and execute unswervingly.”
Daan: “Which architectural goals can be aimed for in a transformation process like outsourcing (for example complexity reduction, greater agility, higher futureproofness, greater transparency, higher user friendliness)?”
Gene: “All those goals and more can be part of outsourcing or, more properly said, outsourcing can be part of a strategy to attain all those goals. Reducing the in-house footprint and outsourcing commodity functions can reduce complexity, focusing in-house staff on core competencies can improve agility, more attention to business architecture rather than running the IT shop can help future-proof you. Outsourcing makes IT costs and services more transparent to some extent but it can also make everything look like a black box. With all the hosting options available today, including emerging cloud offerings, IT executives and architects must have an open mind regarding sourcing at all levels. IT’s relationship to the business is changing dramatically and IT needs to become a supplier of technology and IT services to the business – but it might provision any of those services from outside.”
Daan: “Which business drivers for outsourcing have the greatest architectural impact, both negatively and positively?”
Gene: “The biggest business driver that has a disastrous architectural impact is frustration with IT. This can be from poor service levels, a lack of transparency, poor project execution or any of the typical causes of IT failure. But when outsourcing occurs because the business perceives that IT hasn’t been doing it’s job, it’s very likely to be a scenario that has great negative impact to the architecture. IT (and internal architects) will be out of the loop and the vendor will be able to make whatever deal is most in their favor, which always greatly restricts the architecture options. It’s how they keep their costs down. On the other hand, a business driver of optimizing the organization’s resources to best attain business strategy can include outsourcing as a way to enhance the architecture. For example, think of a firm with a highly variable workload that deploys a hybrid solution that bursts to an external cloud when the workload peaks? That’s a way to architect a cost-effective solution that meets business needs.”
Daan: “Which specific principles are applicable to outsourcing?”
Gene: “I highly recommend that organizations develop their own high-level architecture principles rather than rely on generic ones, so this is hard to answer. Since principles are intended to codify the consensus about what would constitute the right guidelines to use in making any decision, I’d be reluctant to leave any of them out. As for technically-oriented principles, one that comes into play is the location of data. It can be very costly to move large amounts of data around on a regular basis, so one principle that comes with the territory is to be sure that most of the processes occur physically close to the data store, especially when large amounts are involved.”
Daan: “Which principles should as a matter of fact come from the external providers?”
Gene: “Well, you can be sure that the provider will be closely following the principle of adhering to the lowest cost solution. But since their cost structure will also depend on stability, and their business depends on good service levels, the principles regarding a highly standardized environment certainly come in to play. This, of course, is complimentary to a principle about keeping the overall solution low-cost.”
Daan: “What kind of principles have to be included in the SLA’s? Can you give some examples?”
Gene: “Principles regarding standardization are key as they remind everyone that this should all be business driven. Examples ‘we will maintain an architecture that reduces complexity’, ‘simplifies support’, ‘enables integration’ and ‘our architecture will be business-driven’.”
Daan: “What is the real business value of architecture during outsourcing, and how much money has to be spent on that?”
Gene: “The business value of architecture doesn’t actually change from an internally-hosted to an outsourced situation. The real business value of an architecture is its ability to enable attainment of business strategy. That can mean constantly cranking out transactions at an astonishing rate consistently, with little change to the processing characteristics over time, or it can mean adapting dynamically to rapid and constant change. These scenarios are completely different and the wrong architecture can completely prevent the attainment of business goals. An important thing to remember when costing out outsourced solutions is that you need to retain architecture staff in-house to be sure that you can keep the architecture responsive to business needs. That’s a strategic requirement that you can't do without. How much money has to be spent on the architecture itself to attain business value will vary with the needs and outsourcing or keeping processing in-house is only one factor. Outsourcing can improve or worsen the cost profile.”
Daan: “What kind of behavior and which competencies should an architect have to function optimally in an outsourcing context?”
Gene: “The negotiation, vendor management and general communication skills are really paramount. If I had to put it in a single word I’d say ‘diplomacy’.
Architects must be able to communicate effectively with the business and with the vendor; they have to be pleasant and they have to be tough. Of course, they still have to be technically astute or they will not maintain any respect. They are all brought to bear, but certainly the people skills will be tested.”
Daan: “Is it wise to outsource architecture tasks as a service to an external provider? Or is standardization in the architecture discipline still too low to start that kind of engagement?”
Gene: “There are plenty of quite excellent architecture service providers out there; some that are part of companies that provide outsourcing services and some that don’t. Bringing in outside folks to help with architecture is perfectly fine and can be an important way to augment internal staff. As always, the key is how you do it. You don’t just farm architecture out to someone else and do whatever they say. You clearly define your goals and your processes, and you bring architects in to do specific tasks. I don’t mean just low-level technical tasks, you can bring them in for strategy work as well; just make sure it is done under your guidance and that you have provided for appropriate knowledge transfer at the end of the engagement.”
Daan: “So you say that it can be beneficial to use outside architects to supplement the internal staff, as long as you do it well. Is this also true for the Chief Architect?
I can imagine that for a huge transformation, of the size that an enterprise has not yet done itself, you temporarily contract an outside lead architect that has the experience your own architects are still missing.”
Gene: “I think it can make sense to bring in a lead architect from outside but I have as much trouble with the idea of bringing in a consultant for the role of Chief Architect as I do for the CIO role. For both positions you need ongoing relationships with the rest of the organization, and enough continuity over time to pursue an agenda. For a strategic role such as Chief Architect, I could only recommend a consultant on a very temporary basis to fill a gap until you could hire a permanent person.”
Daan: “In my lectures I always state that before implementing an architecture you ought to have it validated by an objective, independent architecture auditor. Can you comment on that?
Does Forrester have architecture audits as a business service?”
Gene: “For any kind of technical design work a third party review is really a good idea, which is why it’s good to have internal central architects or an architecture review board analyze project architectures. It’s a good idea to bring in an outside party to audit for high-impact project architectures or architecture beyond the scope of a single project. It’s important, though, to be sure to find someone objective and independent, though, as you say. Be wary of any consultant making recommendations that translate into more revenue for the consultant’s company. One approach to this is to stipulate in the contract for the architecture audit that no work resulting from recommendations of the audit can be awarded to the auditing company. Yes, Forrester performs audits of architectures as a regular business service.”
Daan: “What advice concerning architecture do you have for CIO’s that decide to start with outsourcing?”
Gene: “Think of outsourcing as just one of many tools. There is no perfect tool for all situations – a hammer is perfect for banging a nail but it’s not too effective cutting wood. Everything needs to emanate from business strategy and goals, and the architecture needs to be able to adapt to future needs. That’s the trickiest part. You can outsource to perfectly satisfy current needs and find yourself constrained to respond to business needs shortly thereafter. Implicit in all this is being aware of the business needs and plans. But most organizations’ business executives don’t plan in great detail many years ahead, and outsourcing contracts are typically multiple years. So it becomes key to understand where the flexibility needs to be instantiated in your architecture. Is it in the applications you choose? The middleware? The platform? The programming language? The information management lifecycle? If you understand that for your business, you will be able to outsource the parts that won’t get you into trouble later.”
Daan: “Gene, thanks a lot for sharing Forrester’s ideas with us. I notice in the Netherlands a growing interest in incorporating architecture into outsourcing deals.
Do you have some final words of wisdom to the Chief Architect about his or her role during outsourcing projects?”
Gene: “The architect’s role in outsourcing is similar to his or her role with respect to anything else at the high level, it’s just the details that are different. What matters is a relationship that provides for a continuing dialogue, getting all the issues on the table, and understanding one another’s risks and benefits. The infrastructure outsourcer’s cost model depends on them providing highly standardized infrastructure and getting a long life out of their technology components. An application outsourcer wants to use the skills they already have. Architects typically argue for standardization in their internal discussions but may find themselves in the opposite position with the outsourcer, trying to introduce something they need for their future state architecture that will diversify the outsourcer’s technical environment, impacting their support model. The architect has to find a path that will make business sense for all parties involved. Strong-arming the vendor or their strong-arming you just won't work in the long term. It’s critical that architects work with the people in their vendor management function to ensure that the contract sets up this sort of dialogue in the first place, and then it’s all about negotiation.”