http://www.ks2inc.com/index.php?option=com_wrapper&Itemid=381

Background

Organizations are increasingly leaning towards SOA as their new architecture, primarily due to the realization that legacy means of integration have not helped them in reducing reliance on the software application vendors and being able to leverage upcoming applications, services and information sources. Legacy applications remain expensive to operate and maintain, and do not provide easy means to participate in the overall Business Architecture supporting critical business processes.

It is true that middleware technologies and architecture such as SOA, BPM and EAI have changed the landscape of how information is exchanged to achieve desired business agility.  These technologies also have the potential to eliminate barriers between isolated application silos and enable reuse of critical business services across the organization.  However the promise of this architecture and technology falls short in delivery due to unanticipated issues, some of which are business related and some are purely technical in nature.  Such unanticipated issues can have serious financial implications on the overall integration budget, as they are discovered during project implementation phases in a totally ad hoc manner This leads to the last mile problem.

Challenge

Typically integration, which is properly done leveraging SOA and Composite Application frameworks, enables implementation of enterprise wide business processes. However the Business Architecture that maps out critical components to implement core business processes, may assume certain functionality in the participating legacy applications and data/information sources such as databases, data warehouses, etc.. Such functionality is not easily accessible in reliable, accurate and timely manner and in the right format, may end up posing huge risks in the later stages of the project.  This issue is well known in the industry as the “last mile” challenge, originating from the telecom industry.

There are several challenges in addressing the “last mile” issue. Although each deserves an elaborate undertaking, we will consider few with the intention of highlighting the issues and potential solutions. Some of these are,

• Inability to participate in business data visibility aspects which are critical to business operations. E.g.  Master data view on all customers, products. A few (but not all) causes of this could be incompatible data formats, incoherent data contexts, etc.
• Stale data or data that is old resulting in inaccurate view of state of affairs. Timeliness of data refresh affects accuracy of data.  E.g. A customer’s account status may be in jeopardy, but not updated in the master view.
• Inability to adapt to changes – change in legacy applications, change in enterprise data model
• Inability to provide adequate data monitoring capability resulting in data quality issues – which could include duplicate records with no defined stamp of authenticity

All these result in data that are inaccurate, not timely and inconsistent which could jeopardize business operations, not mentioning compliance issues.

Potential Solutions

The following depicts a potential architecture for unlocking legacy applications. It assumes that the enterprise has adapted middleware toolsets to facilitate integration.

Adapter Architecture

Just as in addressing any challenges, one should make plans to apply correct methodology and approaches to not only to “unlock” the legacy applications, but also enable them to “participate” in the intended business architecture vision.  Such participation may involve legacy application consuming other services or offering its own business data and workflow to other applications to realize the intended business processes.  Here is where custom adapters, which expose the data and business processes inside the legacy applications to the enterprise information bus, play a big role. Typical middleware vendors make and sell adapters for standard applications like Oracle and SAP, but adapters to the legacy applications inside the enterprise have to be developed from scratch. Thus the problem is not “simply” developing an adapter that exposes legacy data but to allow for operations on the data.  The adapter must also expose “business operations” that would be critical in the overall business architecture.  

The following are some of the critical steps one should consider addressing this challenge of building effective and long lasting custom adapters to the legacy applications:

1. Establishing of data/process ownership/Governance (ICC)
2. Performing “gap analysis”
   • Gap in business process
   • Gap in legacy application data model and standard data model
3. Developing strategy to address the gaps discovered in Step 1
4. Performing application readiness assessment, to study the technical feasibility of “unlocking” the legacy application
   • Web service wrappers for legacy API
   • Recoding legacy application
5. Change control process
   • Metadata analysis
   • Meta-data changes/maps to enterprise data model
6. Mapping & Validation Challenges & Strategy
   1. Data Mapping
   2. Process Mapping
7. Change control processes
8. Operations
   • Monitoring

Technology Factors

Following are some of the features that must be considered and prioritized, before building adapters for the legacy applications. Each application must also undergo a readiness assessment against these tasks to discover potential issues. It also helps to size the complexity of building the adapter.

1. Real-time, batch processes
2. Loose-coupling
3. Model/Meta-data driven
4. Validations
5. Transformations
6. Transaction support
7. Data provisioning
8. Data Security
9. Orchestration considerations
10. Monitoring
11. Scalability
12. Reliability
13. Availability
14. Reusability

One should avoid building point to point interfaces. Looking for already available extracts in staging tables, CSV files and reports should be considered. The way these data sources are handled is also helpful in considerations for migrating to more dynamic environment.  Model driven interfaces accommodate changing landscape rather than having static data model.  But one should be careful not to over-engineer solutions and create ad-hoc interfaces.

The following figure shows some of the tools and framework components required for building adapters.  For example, deployments support requires services such as Notification to notify stakeholders of potential exceptions. It may simply leverage enterprise monitoring tool for that purpose. Whereas Logging, Auditing etc would be needed by any component to facilitate further troubleshooting and/or tracking purposes.

Framework Components

It is critical to understand the role the legacy application plays, in the enterprise business processes. This will dictate the use cases for designing the adapters.  Such use-cases typically representative of sub-processes required in the overall business processes, such as obtaining product master data for compiling bill of materials, obtaining customers from a CRM system etc.  Versioning is another challenge for consideration, as realistically speaking most systems are not static and they evolve.  Change is the only constant. As systems evolve the architecture needs to accommodate new changes. This whitepaper does not go over issues of migration, version support, interoperability with other tool sets etc., as they are topics for another discussion altogether.

Conclusion

How seamlessly legacy applications or the other enterprise applications participate in the SOA strategy determines success rate for SOA/SOI/EAI.  Poorly thought out last mile interfaces can potentially bring down the project.  Clear understanding and best practices are keys to achieving success. There is no replacement for such insights. Having a ready plan helps to address such issues early on in the project lifecycle, and helps in managing the expectations.

Also ICC or Integration Competency Center consisting of technology, policies, people, governance, best practices and processes allow for rapid, reusable, repeatable and cost-effective deployment of business services, meeting corporate objectives. 

Lastly, even more critical is having a business partner who understands these issues deeply and can help achieve your overall success.  It is not sufficient to have a partner who can reengineer and map the business processes in the overall SOA theme. In addition, a technically savvy partner who can bring in the people, processes and technical wherewithal to solve the last mile problems, which crop up however thorough the planning has been, is very crucial. Normally, the business and technical capabilities are found in totally different organizations.

References:

1. http://soa.sys-con.com/node/620374?page=0,1
2. http://www.itbusinessedge.com/cm/community/features/interviews/blog/is-data-the-missing-last-mile-for-soa-success/?cs=31411

OASISのService Oriented Architecture Reference Model TCが作成した

1. Reference Architecture Foundation for Service Oriented Architecture Version 1.0 [Committee Draft 02]

がPublic Reviewにかかっているそうです。　元々SOAの参照モデルを開発したグループが作成したもので、InfoQがその関係も含めてインタビューしています。

1. A Reference Architecture Foundation for SOA Draft Was Submitted to Public Review

SOA参照モデルを詳細化しながらも、個別のテクノロジーには触れないというもので、Realizing Service Oriented Architectures ViewとOwning Service Oriented Architectures Viewという二つの視点に分けて記述されています。　詳細化されていますが、まだハイレベルな記述内容です。　モデリングツール等を用いてアーキテクチャを記述するのに良さそうなレベルですが、今後どのような使われ方をしてゆくのか関心を持って見守りたいと思います。

Before we break away for the Thanksgiving Holiday – I wanted to post an article concerning B2B marketing and the importance of having the neccessary tools in place to manage, track and engage clients, referral channels, and leads.

In today’s world of B2B marketing there are multiple channels used to for audience development, client retention and referral channel development.  These channels typically include the use of various media segments such as:

• eMail (both one to one and one to many)
• Newsletters
• Live In Person events, such as seminars and conferences
• Webinars (both live and recorded)
• Print Media

If this communication is to be effective, the sender must deploy a message of perceived value to a targeted/segmented audience that may or may not include some form of tangible takeaway benefit besides the initial content. For example, offering a free 1 hour online marketing seminar to CPA’s and accounting professionals for referral channel development that is delivered by a marketing expert from a Fortune 100 company and you should expect a 10% participation rate.  If you a add a tangible takeaway benefit to the seminar such as including 2 free CPE credits, your participation rate will increase to 20% or higher.  And your goal for the seminar?  Develop referral channels for your product.  This same scenario can be applied to consumers and businesses alike.

On the surface the above scenario appears to be a relatively benign process. You setup a conference and invite a bunch of people to attend and hope for the best.  However, if you break down the process there is a lot of administrative/organization work involved to achieve your goals.

1. Development, distribution and promotion of event via email and print,
2. Tracking results of that distribution,
3. Event registration and tracking of event registration,
4. Tieback of yes/no responses to database records,
5. Results of seminar; comments from participants, generation of referrals?

In addition to the above:

1. What the event promoted to the correct segment?
2. Did you record who did and did not respond to the event and showed up?
3. Did the attendees refer a client?
4. How does any of this tie into your contact management system? If at all?

The real question is do you have a system in place to perform this type of marketing and event management without a lot of manual interaction?  And does your ’system’  integrate with your contact management system?

In today’s world a professional services firm requires a system to distribute content to all market segments.  The result of the distribution need to be trackable, reportable and return definable measurable benefits to acquire valid ROI costs.  Systems like those developed by Cool Life Systems allow firms to perform this functions for creation and distribution of content, tracking the success of each distribution, and providing tools for follow up with persons in each identified channel.  These tools work together to allow you and your firm to increase competitive market share, achieve market differentiation from competitors and influence audience segments for a desired outcome.

Build near real-time capabilities even if your consumers don’t want them. Your consumer may not want a real-time interface or maybe unable to integrate with one. It is tempting to just go for a batch based solution because, that is what your consumer is asking for. For now at least. However, if you build one off batch file extracts or directly expose your legacy system to make one consumer happy, you will encounter the ill effects of tightly coupled systems.

There are several approaches to achieve long-term reuse goals and address the immediate customer need:

1. Publish a standard message that you will want to treat as a reuse candidate going forward. A subscriber can drain, accumulate messages, transform them to a customer-specific format, and and append it to a file. A scheduled job or process can transfer this file to your customer.
2. Create a reusable service capability that provides the data in the target format that you want to maintain/evolve going forward. You can create a batch process that shares the same interface that the real-time service uses.  Note: volume is a critical factor here though – you don’t want to make several atomic calls when it is more efficient to fetch data in bulk. You could have a configurable parameter for fetching multiple records at a time – the real-time service can use a much smaller number when compared to the batch process.
3. For large data volumes,  consider populating a read-only data store using database replication. File extracts can then be driven off this new database. This has the advantage of reducing load on your operational data stores at the same time facilitating additional consumers who might prefer a SQL interface or a file extract based solution. Downsides: additional moving parts and increased cost for a new data store.

When you build real-time capabilities,  adding consumers doesn’t involve too much effort. Are there additional approaches to pursue?

Like this post? Subscribe to RSS feed or get blog updates via email.

Het hiv-virus is nog steeds actief onder de bevolking. De cijfers liegen er niet om. Elke dag krijgen 3 Belgen te horen dat ze drager zijn van het virus. Besmette personen bevinden zich bij de actieve bevolkingsklasse tussen 20 en 45  jaar. 80% van de hiv-dragers zijn mannen, waarvan 75% homoseksuelen. Dringend tijd dus om de koe opnieuw met de horens te pakken.

Zo doet de Stedelijke Jeugddienst ook zijn duit in het zakje. Op dinsdag 1 december om 16u delen de medewerkers duizend gratis condooms uit aan de schoolgaande jeugd aan de bushalte van het Kolonel Dusartplein.

Condooms zijn nog steeds het veiligste middel tegen zowel zwangerschappen, als aids en andere seksueel overdraagbare ziektes. Ook zullen cafés, feestzalen, discotheken en andere zaken, waar veel jongeren komen, aangespoord worden om gratis condoomautomaten te plaatsen.

www.sensoa.be, www.hasselt.be

Petals ESB v3.0 is finally out (two years after the v2.0 release), there are many changes in this version but here are the main ones :

Petals ESB 3.0, includes a lot of improvements for users, as well as optimisations, and nice new features :
- Dynamic configuration, and hot-deployment of new nodes
- Redesigned webconsole for administration, and deleted statistics monitoring (based on OW2-OpenSUIT)
- SCA support: SCA engine (OW2-FraSCAti), and SCA designer (Eclipse)
- BPEL support: BPEL engine, and BPEL designer (Eclipse), with validation (based on a new BPEL engine!)
- WS Notification and WS-BorkeredNotification support (EDA)
- more and more things…

Integration with new Petals Camelia softwares :
- Petals Studio: Complete Eclipse development environment, for Petals ESB
- Petals Master: SOA Governance (OW2-Dragon)
- Petals View: Business flow monitoring based on Petals EDA feature (based on OW2-OpenSUIT)

We gave this release a name : Camelia.

Interessant bericht van het RIVM. Er is een onderzoek gedaan naar HIV besmetting in Nederland. Het blijkt dat er (naar schatting) 21.500 mensen in Nederland zijn met een HIV besmetting. Van deze groep heeft 55% deze besmetting opgelopen door homoseksueel contact, 40 % door heteroseksueel contact en 4% door injecterend drugsgebruik.

De reden waarom ik dit een interessant bericht noem, is deze: ik was niet bekend met cijfers en percentages en heb me lang afgevraagd hoe de verhouding tussen HIV besmetting door homo- of heteroseksueel contact was. Er zijn binnen christelijke kringen namelijk nog steeds mensen die HIV besmetting zien als een straf van God voor homoseksualiteit (google). Dat is vaak gebaseerd op de aanname dat alleen homoseksuelen of mensen met een zeer promiscue levensstijl HIV besmetting oplopen.

Feit blijft dat HIV ook een SOA (seksueel overdraagbare aandoening) is. Dus een nog belangrijkere conclusie dan de verhouding hetero- / homoseksuelen is het feit dat 40% van de mensen met HIV besmetting zich niet bewust is van deze besmetting. Dit percentage is het laagst in de grote steden en het hoogst in de buitengebieden. Ik hoop/vermoed dat daar de aandacht op gevestigd zal worden: bewustwording.

In my recent post about “Layers” and “Patterns”, I was trying to argue the importance of “Services” and their role (as not the only player) in an SOA.  With that said, I am being reminded of a diagram I used to see describing Enterprise Architecture Frameworks by decomposing an organization into “Layers”.

Wikipedia currently is showing this image:

I believe the intent was two-fold. (1) Identify specific roles and domains and (2) show respective hierarchy to one another.  The latter may be more subtle, but clearly it is important for architects to understand the Business artifacts come first, then the data, then applications, then technology so why not stack them like the diagram suggests.  However, I was wondering why the triangle was chosen?  By using this representation, it seems to typify another generalization, albeit maybe unintended.  The domains on top are smaller then those on the bottom.  Was this on purpose?

I am pontificating now, but is this because we think we need to put more effort in terms of output for those with larger area?  Is this true and if so why not more outcry from the business?  Or maybe we all realize that in practice we see our architectures made up of more from the bottom then the top?  If nothing else, even today I see more energy, more conversation, more debate and more specialization in the technology space then any other domain of Enterprise Architecture.  Is this age-old symbolization of architecture the genesis of unintended consequences: Technology is King and the business is it’s humble servant?  How can that be, the business is at the top right?!?  Well maybe better said, Technology is King and the business is it’s diadem.

Consider flipping the triangle.  Where not only is the business at the top but also consumes the most area.  Then follows data, applications and technology where the bottom is smallest portion of the architecture.  I know this would never fly due to experts smarter than I saying, “It all points to technology and thus counterintuitive” or my favorite, “It does not have a flat foundation, how can it stand?”  Even so, I believe there is some merit in this new depiction.

With the advent of SOA traction in Enterprise Architecture, it should ideally minimize the importance, effort, and landscape of technology.  In a very real sense, technology is merely the interface gateway and maybe infrastructure to the enterprise.  The process modeling, data management, decision intelligence, service components should begin to be extracted from the technology space and become more common place in the business domain.  BPMN, BPEL, rules engines, process improvement and the like are forcing us to get the business people more involved in architecture – the true allure to an SOA.

And since I am busting down some long-standing doors, why not even change the domains slightly.  Why do we even need to bring up Applications anymore?  In the past we modeled our business after COTS or IT limitations, so the application domain is where the real business logic resided.  This lead to it being recognized as it own domain.  Now we realize we should model our architecture, systems, technology after our business.  Allow agility to enable technology to meet the individual need.  In this sense, the application domain has become a Service Layer.  Business oriented services that interact with applications, data or people.  I would still agree that the data domain trumps the service domain in both significance and effort thus higher on the diagram.  Finally that leaves the business at the top that is most important as well most invested in.  The business thus leverages data, services and technology to build the very processes and methodologies that model their goals, motivations, differentiations, etc.

My new diagram would look like this:

SOA non è solo una promessa, ma piuttosto una soluzione pratica oggi disponibile per consentire alle aziende di riutilizzare i propri preziosi processi di business per la gestione dei contenuti aziendali. Le aziende  ricercano con sempre maggiore attenzione le possibilità pratiche di utilizzo  dei protocolli SOA per l’integrazione di applicazioni di Content Management all’interno delle loro organizzazioni.

Adottando un approccio interoperabile – al di là della mera integrazione – con SOA si aggiunge del valore specifico al business,  le organizzazioni focalizzate sul cliente possono ora utilizzare i dati provenienti dalle applicazioni legacy aziendali per definire comunicazioni commerciali personalizzate che trasformano le transazioni in interazioni 1:1 con i clienti.

Utilizzando Papyrus, le modifiche nella corrispondenza commerciale non richiedono cambiamenti nelle applicazioni legacy, perché il repository di metadati della piattaforma gestisce tutti gli accessi e le interazioni con i contenuti provenienti da questi sistemi esistenti.

Leggi qui l’intero articolo (PDF) che include un interessante esempio di applicazione.

Business applications often utilize log files and databases to capture metrics about usage and error patterns. However, analysis and pattern detecting becomes challenging with additional data and system complexity.  Tree map visualization of application metrics could greatly aid rapid view of system state, error analysis, trends, and remedial actions.  A tree map visualization can be generated using metrics from a database.  It can generate useful views and present information of use to both business stakeholders and the system support team.

Service View – a treemap of metrics organized by service invoked on your SOA platform. The idea is to provide a comprehensive view of the metrics captured and answer questions such as the following: which services are being invoked in the system? Which services receive the highest volume of invocations? How does the volume of service invocations compare with each other? What proportion of invocations in each service was successful and what proportion ended in generating errors?

Transport View – a treemap of metrics organized by kind of transport used to invoke requests in your SOA platform. This is especially useful for systems support staff who need to quickly assess the system-wide impact of messaging providers and their non-availability. The idea is to provide a transport-level view of the metrics captured and answer questions such as the following: what are the transports used by clients when invoking services in your SOA paltform? Which transport mechanism is being used to process the bulk of requests? How does volume of invocations via a transport compare with one another? Which transport is having a higher proportion of errors? Are the failing invocations using reliable transports or are they using unreliable ones?

Status Code View – a treemap of metrics organized by kind of status codes that service requests returned. This is very useful for both development staff and systems support staff. This view displays a bird’s-eye view of the metrics with respect to return codes and answer questions such as the following: what service codes are being returned to clients? What proportion of codes are success codes and erroneous codes? What is the volume of error codes with respect to each other? In summary, this view provides a sense of how the system is performing as a whole – what matters most is whether the platform can provide good response to clients and this is a succinct visualization that answers that.

Are there additional opportunities for visualizing metrics using data in your services layer?

Like this post? Subscribe to RSS feed or get blog updates via email.

On November 21st and 22nd as many as 20,000 protesters protested the School of the Americas at Fort Benning in Columbus, Georgia. The demonstration is organized annually by the SOAwatch and is held as a peaceful plea to shut down the school.

The school has gained the nickname of The School of the Assasins since it has been attributed with teaching some of the war criminals, dictators, and assasins in Central and South America.  Many of the graduates of the School of the Americas have gone on to lead military coups and overthrow diplomatic governments in the Americas. A very detailed speach about the school as well as the protest can be found here with the speach of SOAwatch’s founder Father Roy Bourgeois.

Bradley Ennis is a photojournalist and senior at Eckerd College in St Petersburg, Florida.

BradleyEnnisPhotography.com

Pattern-Oriented development is paramount in IT.  Patterns are used for designing software [POSA], integrating applications [EIP] or building enterprise systems [PEAA].  They make us feel comfortable that are our solution in the end will be extensible, reusable and hopefully along the way we managed avoiding some age-old pitfalls.

One thing enterprise software architecture teaches us is to rely on layers.  There are various patterns and styles of layers but more than likely if you are missing layers you are missing the mark with your framework.  Inside the context of integration landscapes and even application development, the introduction of “services” has greatly improved our ability to leverage layers well – make them more understandable, reusable and frankly standard.

Services & Layers

Services can mean lots of things, from a simple exposed interface to a data object, to an managed end-to-end business process, to an  interactive SOAP web service or EJB.  But at the end of the day, the term service has become common with the “stuff” or components we should be interacting within our layers.

If it’s a data layer, then provide me data-access CRUD like services.  If it’s a domain layer, provide me with business process logic.  If it’s an application layer, provide me with interface adaptors.  It it’s a presentation layer, provide me with representational views. And the list goes on and on, but we all agree we should be employing our patterns with services in mind in both development and discussion.

Does this therefore mean all architecture lends itself to Service-Oriented Architecture?  Well – no.  Service abstraction is something service-oriented architecture leverages but in practice an SOA is far more.  Furthermore, I contend that due to this lack of understanding, there is a very high risk of creating a “Service Architecture” (SA) and missing the boat all together on the sought after “Service-Oriented Architecture” (SOA).

Service Architecture

The SA is something we rarely talk about and only whispers can be heard of it in JAD meetings, or final production audits.  As a definition, I will give it this:  An Integration Landscape focusing on providing interoperability primarily through exposing and managing services across the enterprise.   In short, take your spaghetti code and stovepipe applications – re-architect them using services and layers (ignoring the true patterns from whence they came) – and you are left with an expensive replica of what you had: a point-to-point mess only this time with fancy service names attached to all those tightly-coupled interfaces.  And just because you decided to run all this on top of the latest “ESB” you hope to god the resultant SOA guarantees all the power it touts.  For this reason, I have grown to hate the term “integration point”.  As if all I need to do is define some necessary communication /action and provide some code to interoperate and “voila”, a true “service” comes out and now we are on our way to an SOA.  Sorry to say nope – designing integration landscapes by focusing on integration points, will usually get you quickly to a place where “web” and “point” are frowned upon.  (Referring the web chaos of point-to-point architectures).  Unless of course you were going for P2P, but since this BLOG is about SOA, I would assume you are not – and thus frowning is applicable.

Service-Oriented Architecture

SOA has evolved to mean so much, maybe too much, but at the least it is associated with a series of highly desired characteristics of enterprise application architecture.  Benefits like agility, governability, real-time, guaranteed, extensible and intelligent add to our ROI while benefits like reusability, maintainability, operational efficiency, automation, auditability reduce our TCO.  So how do we ensure we get all this?  Is it even possible?  Or is SOA another ivory tower pipe dream big software vendors and consultants are helping us peddle?

Check out some of my previous postings for definitions of an SOA – but in short, I would have preferred the “S” stood for Standard.  As in the tried and true standards that have really stood the test of time and now we finally are smart enough to realize it and start repeating it rather than conjuring up something new for our own ego sake.  However, for this posting I will offer this up for defining an SOA: An Integration Landscape that provides both interoperability and infrastructure through a strategic enterprise solution embodying connectivity, consolidation, composition and completeness.  Before I get hammered by the SOA for dummies people who say where is mention of the business people, this is meant to constrain SOA as an integration landscape not a project methodology.  I am not trying to redefine IT departments and IT business as we know it, just pointing out that when I look at what was actually implemented, how can I tell if it was more of an “SA” or “SOA”.  Besides, I added words like “enterprise” and consolidation to include the “business” (yes the stakeholders and business owners are important) – you cannot achieve consolidation or completeness without the business. See my blog on SOA Maturity.

The big deal here is the combination of technology, infrastructure (IT resources and Business resources where resources are people, processes and tangible assets) and standardization in a way that shows evolution and maturity of thought on both sides.  ESBs, web services, integration points, BPM or even technology patterns can not achieve this alone.  For an SOA to begin to produce all the benefits it so badly wants to, it needs some old school experience to pave the way.  Don’t throw out all your old PM methodologies or Architectural gurus in favor for new age hype.  Slow down, question why, document decisions points, make sure you are actually modeling your business not technology or a deadline, and for goodness sake, make sure the solution everyone is going for actually makes sense.

Problem Statement

A consuming application/business process wants to integrate with your reusable asset. However, the consumer doesn’t want to take your standard message – wanting a specific format that will make it easier for them. Why? Could be because of several reasons: lack of time/money/skills or technical limitations (e.g. their system can handle only delimited files and cannot parse XML).

Suggested Approach

The immediate, tactical (and often tempting) solution would be to just format the data per the consumer’s format and integrate in a point-to-point fashion. Don’t settle for this option too quickly! Prefer to publish a standard publication in that is in line with your long-term direction (e.g. offer reusable message publications in XML format indicating changes to critical data entities or state changes in business processes). Create a subscriber that tranforms the standard message to the consumer-specific format.

Rationale

If point to point integrations go ungoverned, you will end up with a rat’s nest of tightly coupled integrations that ultimately hurt business agility.Your long-term intent is to have multiple consumers (web applications, backend systems, business processes, etc.) consume reusable message publications.If several business processes need the same core data or notifications about state changes, why would you want to integrate with them separately? Publications will not only reduce integration effort, they place less strain on your system resources – publish once and subscribe several times. No need to query databases or invoke external systems every time there is a new integration.

Note: The additional transformation logic will require extra logging/error handling but over the long haul is a better option than going for a point-to-point integration approach.

This will enable the asset provider, to integrate new applications faster (no need to custom develop messages and integration code for every new consumer) and reduce the cost of maintenance. Reducing application to application coupling is a key motivation for pursuing this approach as well.

Like this post? Subscribe to RSS feed or get blog updates via email.

This morning it was exclusively reported by the Army Times that a threat letter was found yesterday at the Fort Benning, GA army base. The letter vaguely says that if the commanding general doesn’t call off all charges there will be a re-enactment of Fort Hood. The treat level of the base has been increased according to the Army Times, accompanied by a serious increase in police presence. The Atlanta Journal-Constitution also reported on the threat, attempting to tie it to General Petraeus’ trip to the base for Officer Candidate School Operation.

Neither the Army Times or the AJC mention that the appearance of this note warning of a Fort Hood repeat occurred on the same day as the School of the Americas Watch protest at Fort Benning, GA, the largest annual protest of a US military establishment in the country.

This isn’t an error in journalism. The note is a fake. The reporting is a fake. Fort Hood is a massive US Army base. You would think, in the wake of the Fort Hood shootings that this might be national news. It isn’t. And because this isn’t being reported widely at CNN and other national outlets, the usual ratcheting up of public fear doesn’t seem to be the play here.

The SOAW protest is the target, which last year brought 20,000 people to the bases gates. Look for something unbecoming to perhaps happen this year. Looking out my hotel window I see flashing lights whizzing by and cops pulling people off of Columbus streets left and right.

The timing of this news story is such that it won’t discourage protestors from attending the event. It came out to late. Maybe the fake note was meant for something else.

http://www.metromidrange.org/meetings.shtml

Episodio 11 gustato per bene!!
I nostri amici sempre più ciulotti, il vero manico è la Gemma, lei è il vero cuore pulsante di Samcro…

Subisce e gestisce tutti i SoA

Un consiglio: non fatevi più vedere al club senza la toppa

Top 5 Problems with Service Today

We’ve all been the victims of bad service. We have to repeat ourselves to agents; we get different answers depending on whether we use email or we call a service rep; or worse, we don’t even receive a response. We have a tendency to blame the agents.

But it’s not their fault. They want to do a good job. They just don’t have the tools they need to meet customers’ expectations of personalized, consistent, accurate and fast service. They don’t have the tools because their technology isn’t working.

Thus, I trace bad service to 5 root causes:

- IT organizations have not solved the integration problem. Agents need dozens or often hundreds of un-integrated tools and applications to perform their jobs. Agents must toggle through many applications in the span of a service call, resulting in long hold times.

- IT organizations have not solved the change problem. Agent tools are typically hardwired together. When procedures change in a company, IT organizations cannot quickly respond to the changes in order to give the agents the new tools that they need.

- Knowledge management vendors have not solved the knowledge problem. Corporate knowledge exists on an island; it does not fit into the context in which agents are searching for content. This means that agents need to wade through many solutions in order to find the one that is right for a particular customer.

- Case management vendors have not solved the business process management problem. Today, business or call center leaders can’t drive agents through clear processes. This means that they put the responsibility of following the right resolution processes in the hands of agents, which are not all equally competent.

- Organizations have not solved the agent training and turnover problem. Businesses know how they want service delivered, but they can’t have their best, most highly trained agents handle every interaction.

How do we start solving these problems? We start with technology. We implement service-oriented architectures (SOAs) to begin integrating systems in a flexible way so that information is no longer siloed. This means that when processes change, IT systems can be rewired easily, without a tremendous amount of overhead. We ensure knowledge is it’s shared and applied appropriately. We present in a way that makes sense to agents, and we use it to inform our decisions about what’s working and what’s not working in our service processes. We provide agents with stepped procedures for each and every service interaction that allows them to provide the consistent service that we desire. If we are able to achieve these goals, and provide agents with the tools they need to succeed, then we’re solved our final dilemma. Because every agent becomes as good as our best, most highly trained agent.