Articles Archives - Page 394 of 417 - Business Analyst Articles, Webinars, Templates, Jobs

ITIL for BAs. Part V; Service Level Management

Written by Terry Longo on December 15, 2008. Posted in Articles. 1 Comment on ITIL for BAs. Part V; Service Level Management

Our previous post discussed the value of the Service Catalog in representing IT’s general capabilities, expressed in terms of IT Services, described in the language of IT’s customers. To quickly recap:

the Service Catalog represents the current state, and committed-to-future state, of IT’s capabilities,
Service Level Agreements (SLAs) represent the current state of the relationships between IT and its customers in terms of service delivery commitments, and
the Service Catalog Manager is responsible for ensuring the completeness, accuracy, and fitness for purpose of the catalog

The service catalog manager, however, is not responsible for ensuring that the right services are being cataloged – that responsibility belongs to the Service Level Manager, the key liaison between IT and its customers.

It can be easily argued that the service level manager is the IT business Aaalyst. Just as the “business” business analyst is responsible for the entire life cycle of the business requirements and the suitability of overall business solution, so the service level manager is responsible for the entire life cycle of the IT Service requirements and the suitability of the overall IT Service solution as a contribution to the overall business solution.

Note that, as I have proposed numerous times in the past, there is a basic assumption that the overall business solution includes non-IT components as well (internal/external marketing, training, Both the business BA and the IT BA (the service level manager) follow a rigorous life cycle based process of managing requirements, and the distinction is a matter of scope only. The Business Requirements Document (BRD) from the business BA will contain the requirements for the IT service as well as the requirements for the non-IT solution components. The service level manager will run with the IT service requirements (and in fact will have ideally been engaged with the business BA early in the process of developing that BRD, identifying the appropriate solution, and formulating the supporting business case).

From a process point of view, the service level manager and business BA work together through all aspects of the IT service life cycle: strategy, architecture, design, development, release and deployment, operation, continual improvement, and retirement. The types of inputs from the business BA into the service level management process are too numerous to list here but can be generally categorized as

functional requirements
non-functional aka supplemental aka Quality of Service requirements (ITIL’s preferred term), including availability, capacity, continuity, security, and manageability requirements (each of which essentially has a corresponding owner within IT, e.g., Capacity Manager, etc.)
service monitoring, reporting, and reviewing requirements

The parallels between the service level manager as defined by ITIL V3 and the business analyst as defined by the BABOK, and the business BA – service level manager relationship, are significant. For the enterprise grappling with the question as to whether the BA should be hosted by the business or the IT organization seems likely to become fairly settled once an IT organization adopts ITIL. It seems sometimes that the distinction between the two roles becomes clouded by the magnitude of the complexities and risks of the IT components of the business solutions. And indeed those complexities and risks merit a lot of attention!

Does your IT shop practice ITIL V3? Does your enterprise have some form of a BA Center of Excellence? If yes to both, does your enterprise Business Analysis model recognize the Service Level Manager as a “business analyst” with an IT specialty? I hope to see your comments below.

In the meantime, may you and yours have a long, relaxing and love-filled Holiday!

Trends in Business Analysis and Project Management to watch for in 2009

Written by Cynthia Low on December 15, 2008. Posted in Articles.

The close of the year tends to make one reflect on the past and ponder the future. Here we ponder some trends in the business analysis and project management fields for 2009. We invite you to read some of these trends and ponder for yourself our views about what project professionals can do about them.

Convergence of PM and BA Roles. As the economy tightens, organizations will decrease their project budgets. But, they still need projects done, so look for organizations to try and combine the role of the BA and PM on projects. A recent survey on BA Times finds that an equal number of “project professionals” (our term to encompass both project managers and business analysts) feel that the PM and BA role will be combined on many projects in 2009. Project managers will be asked to do more requirements elicitation and analysis. Business analysts will be required to manage more projects. Oh, and by the way – you will need to do that in addition to your normal roles!

What Project Professionals can do about it: If you are a project manager, sharpen your requirements elicitation and analysis skills. If you are a BA, learn how to plan and execute projects better, and to manage risks. The other advice we can give is “Concentrate on the work, not the worker.” No matter what your job title, make sure you know the tasks and outputs expected of you to help achieve project and business success.
Greater Emphasis on Requirements in Project Management. The upcoming 4th edition of the PMBOK® (Project Management Body of Knowledge) is due to be released in 2009. The Project Scope Management Knowledge Area contains a new section 5.1 called “Collect Requirements” that was largely written by us (Elizabeth and Rich). It contains a number of requirements elicitation techniques that project managers should be able to use to elicit requirements for projects. They are a subset of the techniques described in the Business Analysis Body of Knowledge (BABOK®), so BAs also need to be familiar with these. The section places an emphasis on the Requirements Management Plan and use of the Traceability Matrix for managing requirements and product scope.

What Project Professionals can do about it: When the new PMBOK® Guide becomes available, make sure you obtain it and read the section on Collect Requirements. It’s not because we wrote much of it (well, we are proud of it!). Both PMs and BAs should be aware of what this widely-used and referenced guide says about requirements. The PMBOK® has heavily influenced the practice of project management the past several years, and the new edition promises to do the same.
Change in Requirements Approaches. We see a continued trend in business analysis techniques continuing into 2009. Here are some to consider:
1. Slightly less reliance on use cases and movement towards user stories and scenario-based requirements. Use cases will still be used, especially with complex requirements with intricate interfaces or tricky infrastructure considerations.
2. Less emphasis on requirements specifications, more emphasis on modeling, prototypes and diagrams. For many reasons, there is a trend away from only formal written requirements specifications. That doesn’t mean written requirements have no place, but it does mean the industry is using additional methods of documenting requirements.
3. More requirements management. To control scope and fulfill business needs, there will be continued increase in business analysis and requirements planning in 2009. We see more and more organizations using traceability to control and manage product scope. Both the upcoming PMBOK® and current BABOK® feature this technique and emphasize the use of a traceability matrix.

What Project Professionals can do about it: Keep using use cases, but bear in mind there are other good requirements analysis techniques. Supplement your requirements specifications with models to document and help you better analyze requirements. Learn about other methods, such as user stories and use the technique most appropriate for the type of requirement you are analyzing. For example, do data modeling for refining your data requirements.

Increased use of Agile Approach and Techniques. Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue as organizations adopt Agile techniques and the industry adopts commonly accepted practices. Agile itself is evolving to the needs of the industry. For example, the need for more planning has been recognized. For instance, the concept of “Scrum of Scrums” to coordinate Agile teams has surfaced. Another trend we’ve noticed is Agile teams incorporating traditional techniques like requirements workshops and more documentation.

What Project Professionals can do about it: Like any new approach, make sure you learn the generally accepted practices, not just the way a consultant or a single “expert” advises. There are many self-proclaimed experts out there, and some shortcuts on planning and requirements are being taken and justified by being called “agile.”
BABOK® continuing to have an impact. The practice of business analysis is being positively influenced by the Business Analysis Body of Knowledge (BABOK®). The BABOK® Knowledge Areas of Enterprise Analysis are beginning to gel in organizations, as is the need to do requirements planning. We’re seeing more formality and standardization in the methods, say, of doing business cases, or using traceability to manage requirements.

Also, the various elicitation techniques in the BABOK® area are being more widely adopted. Interviews and requirements workshops are common forms of elicitation, but we feel the BABOK is influencing BAs to use additional techniques such as prototyping and interface analysis and to include them in their requirements planning.

What Project Professionals can do about it: Download the BABOK® from the IIBA and start reviewing it. Use it as an input to recommending business analysis standards in your organization. Being some of the firsts CBAPs (Certified Business Analysis Professionals), we believe in and urge others to pursue certification in business analysis. It helps promote the profession of business analysis in general and helps you to solidify and integrate the tools and techniques in the BABOK®, and to “personalize” them to your organization.
Business Intelligence Continues to Grow. This area of information systems has been growing steadily and 2009 promises to have no letup. As BI tools and techniques improve and solid benefits are realized, organizations will invest more and more in this tactic. Since BI relies heavily on tools such as Business Objects or Cognos, the underlying business requirements can be easily overlooked in favor of what the tools can produce.

What Project Professionals can do about it: Learn how to identify how BI can help your business perform better. BI applications should be actionable and project professionals should focus on true business requirements instead of particular tools. Learning to ask the right questions is key, and anticipating how clients will use their data, although challenging, is well worth the effort.
“The Economy, Stupid,” as a past political slogan said. A slumping economy tends to affect travel and training budgets, and this one is no exception. That translates into fewer trips to national conferences or travel to out-of-state training classes.

What Project Professionals can do about it: Attend local conferences that you can drive to. Many local chapters of PMI and now IIBA are launching Professional Development Days or PDDs. Watch for announcements to these and plan to attend. If you have a conference such as Project Summit/Business Analyst World in your town, take advantage of the opportunity and you will find excellent speakers and workshops there. Have you noticed the big increase in webinars as a way of exchanging information and interacting virtually without travelling? Watch for more of the same in 2009. We plan to offer regular webinars throughout 2009.

Interestingly, national conferences like the PMI Global Congress North America attracted many foreign workers this year, from expanding economies such as Brazil and Russia. These growing countries will have larger travel budgets than some of their US counterparts. We also see continued rising international interest in PMI and IIBA.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

Stories from the Front!

Written by Marcos Ferrer on December 15, 2008. Posted in Articles.

We are STILL receiving REAL news from BAs and CBAPs at the front lines. Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

I spent about six months refusing a Connecticut based Enterprise Architecture-based job. This was all related to my BA resume and CBAP certification. Recruiters simply wouldn’t go away, though my on-line profile and response was always clear – “not going to Connecticut”.

In the meantime, I got a few direct phone calls, from hiring managers – a little more fun than recruiters – and landed a contract to assist a government agency implement some BA BOK based standards. For me, this is a dream job, a chance to help create an environment where BA is supported (even championed?).

After four months, things are going pretty well – executive involvement is way up, and stakeholders are eager to move to next steps.

The backing is all due to IIBA, the BA BOK, and the CBAP, vendor neutral certification. As always, I am just one more voice in the project, it is the BA BOK that speaks surprisingly loudly, and surprisingly effectively.

Story 2

Not much has changed for me – I have been in a stable, and respected and supported position for several years.

AND we did have some hairy debates concerning data vs. business data vs. data modeling and who had influence and responsibility – my use of the BOK helped settle the matter more quickly and easily.

Story 3

I was engaged by a government agency to introduce BA standards and practices. They worked with me for over nine months, and loved my work, BUT finally told me that they just weren’t ready to make such big changes.

After consulting BOK I realized that I had allowed myself to work on a TO BE, without insisting on eliciting an AS IS. Next time I will not miss this, and will be able to tailor BOK to the actual situation, instead of the ideal one.

De du, de du, de du…that’s all folks!

Keep sending me your war stories!

————————————————————————————–

NEXT MONTH: YOUR STORY HERE or I will be forced to tell mine!

Thanks to my gentle readers for their frankness and willingness to share.

More shall be revealed. Have fun!

The Business Context Model; As Good as it Gets

Written by Suzanne Jane Maxted on December 1, 2008. Posted in Articles. 2 Comments on The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family. I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: LD, BL, JM, HT.

Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children. Suzanne can be reached at [email protected] or [email protected]

The Uncertainties of Integration Projects

Written by Cynthia Low on December 1, 2008. Posted in Articles.

Integration is burdened by a lot of misconceptions. The uncertainties of an integration project can be deep enough to evoke hundreds of questions, specific to a company’s back-end systems. This article will focus on five common thoughts where we have seen Integration sales reps dance around one or more questions, possibly because of either shortcomings in products or a lack of knowledge on how Integration really is implemented.

Building Integrations isn’t really easy, right?
How much will I need to spend on professional services, and what particular expertise will that entail?
What is the true time to develop integrations?
What are the real costs/options of the software?
With all of the Standards out there, isn’t Integration pretty straightforward?

Mid-sized organizations may undertake either internal or external Integrations, and projects can cross over data formats and system boundaries. One good example is integrating order data from an on-line store (typically in XML or an intermediary DB back-end) to an ERP system. It’s what many think of as a singular or monolithic integration: it connects two points, crossing data formats and system boundaries.

However, that’s only part of the picture. You may also want to move the information into a CRM application as a subsequent transaction. This can be thought of as a complex (or multi-step) Integration. Some other examples of Integrations involve legacy data movement, EDI, and XML Interestingly, we are seeing an increase in spreadsheet-to-application integration, as spreadsheet formats emerge as a lower-end data-exchange standard du-jour and, as such, represent a tempting staging area for incorporating into other applications.

Why integration matters: islands need to communicate within a company.

Most mid-sized companies have IT departments that are stretched very thin, for any of several reasons:

Limited staff and resources;
Lack of knowledge and difficulty in finding impartial advice;
The cost of solutions;
Lack of time to devote to implementation and maintenance;
Short-range management perspectives;
A lack of understanding of the benefits that IT can provide, and how to measure those benefits;
Lack of formal planning or control procedures.

Without these limitations, many if not all the questions would be irrelevant. But they do exist, and lead to inevitable questions.

Q: Building integration isn’t really easy, right?

A: This is the ugly truth about integration projects. Typically, they’re tough going. There are tools that can help, but you still need to be prepared to get in there and roll up your sleeves.

There are several considerations, not the least of which are the data formats to be used (How well do you understand the data formats and processes?); the processes to define; communications methods; if you are doing an external Integration, how cooperative is your partner (well-defined specs)? What information have they provided? And, what skill sets are available in-house to achieve this understanding?

Integration does not need to be difficult if customers have an understanding of the following “whats” or variables:

Ability to work with data definitions, create definitions that can be re-used;
Easy-to-use mapping tool (graphic, drag-and-drop, connect source and target info. Avoid writing code);
Business process management, something that is often overlooked. We find that companies are conscientious about the data, but often forget about the processes, and how they can improve them or accomplish more with what they have.
Flexible way to use communications adapters. Without them, a company’s infrastructure can really be over-burdened.

So, the key to making the “how” easier is understanding what the tools can do for you. There is a direct link between the capabilities of the tools and the ease of building the integration.

Q: How much and what kind of professional services will I really need?

A: It depends on a few key factors. The first, most logically, is the size of the integration project; then, the capabilities of the tools used; and especially the in-house skill sets.

For large integration projects, “point solutions,” especially where manual programming is involved, can run from 4x to 10x the cost of the software. The sophistication or complexity of the tool, versus in-house skill sets, tends to define the need for consulting. The in-house capabilities need to be aligned with the capabilities of the tool. This may not be an obvious point, but it’s important to keep in mind. You don’t give an 8-cylinder roadster to a new driver, nor send a jet pilot to operate a back-hoe; match the tool to the skills and experience of the user.

Users can, in fact, leverage a pilot project as a mentoring stage, something we see pretty routinely. The real key, where I have seen the best ROI, is to define a small pilot-project and engage a professional services group to mentor your team. This allows a skill-set transfer, won’t consume a large amount of resources, and produces a usable Integration, rather than a throw-away.

In other words, the pilot project doesn’t go away after implementation, it actually goes into production. The concept has been proven, and the results are immediate. Because of the capabilities of contemporary Integration tools, these pilot projects only last a few weeks. They can be an effective way to measure the rate of knowledge transfer and still end up with a usable result.

Q: What is the true time to develop integrations?

A: Several factors tie in to the first question (Integrations aren’t really easy!). I’ve worked with companies where the IT folks staff the new systems inside and out. They were able to grasp the tools and run full-speed. We also have the converse situation where a smaller company has a business analyst who is savvy and is thrown into the mix as the Integration person. They have “some” knowledge of the processes, a passing familiarity with the data formats and a limited background with the notions of mapping and data conversion.

Then, we have “the rest of us.” So, this is too broad a question to answer generically. There are usually metrics available, for example, to map an EDI 4010 Purchase Order into a back-end database. Even though there are tons of DBs out there, you are still doing similar things (header/detail records etc). Professional services teams usually have a good handle on these types of metrics.

The answer lies within the capabilities of the tool and how easy it is to understand and start leveraging it. A good example is a tool that can take a flat-file document and allow you to easily “discover” the structure of the document. That would save you from having to build the data definition by hand. Web services have been designed from the ground up to aid this process by providing a schematic of the services and request/response data formats within a descriptor document called a WSDL. This self-describing nature is also inherent in XML documents, but requires a dictionary to leverage the business relationships of the data.

Understanding your business goes a long way towards developing integration. That is, besides understanding the company’s own business processes, it helps to also have an understanding of the data formats. Awareness, from the general to the specific

There are no real absolute answers, just a range of times that have been observed from projects. However your first pilot project should definitely be scoped to only take a few weeks to a month. You want to attain a completion, without burdening the user with a large knowledge-transfer upfront.

Integration tools can help accelerate the process, and a few key principles come into play:

Easy-to-use visual tools reduce learning curve
Reusable objects improve development efficiency
Integration tools can reduce complexity and therefore reduce dependency on consultants

Testing the Integration is a key area that gets lost in the time estimates, so always keep that in mind.

Q: What are the real costs/options of the software?

A: By their very nature, most sales people want the prospect to buy the whole enchilada. They want the prospect to think of integration architecture and enterprise-wide solutions together. The fact of the matter is that there are packages designed for the company to buy just what they need at the present moment, and allow them to grow into the full solution later.

Oftentimes, a sales rep. has the option to sell you less than the full-blown system, but may not let you know that until you ask. Depending on your corporate setting, you may be addressing a mandate such as an EDI standard from a large trading partner. In that case, you are looking at a tactical solution with some interest in moving into Integration at a later point.

Given the complexity of enterprise-systems today, it can also be overwhelming to think, from the start, about all the touch-points where Integration would be a benefit. Being able to buy a “slice” of a full Integration solution is a valuable way to solve your immediate need, and introduce you to the technology at a hopefully lower price-point.

Finally, be cautious of hidden costs, such as training time/ramp up.

Q: With all of the Standards out there, isn’t Integration pretty straightforward?

A: Yes, one interesting thing about standards is that there are a lot of them (see graphic, for standards relevant to Integration); and they all want you to do things their way. That’s why they call them “standards.” But, there are no “formal” integration standards, just technology standards. There are ways of thinking about Integrations, templates or patterns to follow, but no hard-and-fast rules on how to do Integration. It’s not just about connecting the dots.

Quite often, standards are simply guidelines Understanding your data and processes is a fundamental requirement when thinking about Integration.

Let’s talk about one of the real reasons why Integration exists; it’s what I call the “Standards Oxymoron”… the notion of standards regarding data. There are standards for what the data looks like, how it is transmitted, etc. There is one great thing about these standards; they are so popular that you have a lot to choose from. Every flavor of data has someone attaching a standard to it, from XML (RosettaNet, large-customer proprietary formats) to the EDI (X12 and EDIFACT). That is why we are talking about Integration; if we just had one common layout for File and Database, we wouldn’t have a lot of these issues.

Another aspect is the agility to deal with new data formats, as they emerge. Spreadsheet formatting is at the forefront of this movement. Whoever would have predicted: spreadsheets as a common data foundation for Integration?

Being equipped with these questions will better prepare a company to deal with the inevitable promises and uncertainties of an integration initiative. Considering a few of points will be especially helpful.

Start with a pilot project and mentoring
Think strategically: where is your business going?
Ask yourself, “Do I need the whole picture or just the key pieces first?”
Your existing team, with their existing skills, can be successful.

Vendors ranging from software companies to integrators to some-of-each will do their best to sell their approach. Knowing the questions will better equip you to sift through the answers.

Mark Denchy is Director of Product Management at EXTOL International. With more than 20 years’ experience in the software field, he has a wide-ranging background in application development and platform integration. He works with several clients on leveraging new technologies that enable integration.

This article originally appeared in DM Review