Five execution strategies for outsourced product development

In the world where outsourcing is the norm, the percent of business application  outsourced for custom development, maintenance and support is approximately more than 70% in my view. This is quite a huge change in the last decade or so. With all the positive impacts it brings with cost reduction, flexibility, reduce time-to-market, it has also given birth to challenges in quality of deliveries, communication gaps, overheads etc.

The most important challenge in outsourced custom application development type of engagement is  to "Manage Design & Architecture" of applications with respect to completeness, aligning with principles & guidelines, value realization, and ensuring robust application in production.  How do teams working Onshore-Offshore models ensure the design is well built, architecture is well communicated, quality is ensured, and discipline is maintained? How do teams organize to ensure Architecture & Design function is well represented and given due weight-age? Why do customer's see delay's in delivery for small changes? These are some questions that force customers and their vendor partners to re-look at their execution model.

From the perspective of software methodologies followed, every customer has their own customized processes that are followed by vendors with minor changes. Many still follow the standard water-fall kind of model or some hybrid model to suite their working culture. There has been noticeable rise in adoption of Agile methods by organizations, they are yet to be in mainstreams in outsourcing model. Here I would  focus on strategies that are proven to improve outsourced execution capabilities, that would result in successful deliveries for outsourced vendors.

1. Get the Skill mix right: For custom development engagements, having the right skill-mix is very important to ensure your start with right foot forward. Always ensure you have engaged Solution/Application Architect upfront at the start to benefit in the long run. It is often noticed that Business Analyst are performing the role of Solution Architects due to unavailability of people. It is this role that is key to map requirements to implementation making sure we align to business needs.It is recommended for complex engagements to have Solution Architect working close to business, while Technology Specialist working with Offshore teams.
2. Get the Method right: By Method I mean method of delivery for Architecture & Design process. Architect need to use innovative ways to represents and communicate design to the team, business and other stakeholders. Architect need to take lead in modelling design decisions, technology selection decisions, highlighting risks, challenging business on the requirements if needed. All needs to be documented and shared to stakeholders. If one follows the agile approach the design is part of the implementation, the validation happens with implementation, but it also needs agile modelling to help communicate design approach and decisions to remote teams. 
3. Get the Discipline in the team: At the end of it all, it is people that make the team, their collaborative and synergy is going to bring the success to the engagement. Hence it is very important to build discipline. This needs a leader, coach, mentor and more importantly passionate person to imbibe good practices to his team. Introduce good practices for requirement management, source code management, build management, collaborative design and prototyping, release management, and automated testing. It requires discipline and motivation in the team to do successful execution. Discipline brings common focus and build synergy. But it is the most difficult job as a leader.
4. Get to the Hybrid-Agile approach: Agile approaches have begun to be accepted by outsourcing vendors. Adopting pure agile is difficult when customer and vendor are not ready for it. Often the customer team is not ready for agile approach, their processes are too rigid and not ready to take the plunge. Many customers are in this situation currently, but to improve value of outsourcing it is recommended to adopt a hybrid-agile approach. This means having shorter cycles of executions called iterations, requirements in concise documentation, automated test and build process, regular customer feed-backs on deliveries, complete visibility of effort spent. Often the customer teams are rigid and not geared to work in agile model. This has to change to persuade vendors to work more with agile practices that results in better value-realization in outsourcing.
5. Get the Hands-On Architects: Role of Architects need to change to include more hands-on approach with the teams. This is very important in the starting phased where the design is shaping-up and decisions are made for long-term outlook. The average-experience of teams by outsourced vendors is relatively less, it puts much pressure to give a good start in the starting phases. Having hands-on Architect in very important in critical projects. Architect has to define and develop interfaces and modularize the important architectural components, design framework fundamentals and guidelines, establish strategies for important requirements and cross-cutting concerns. This reduces pressure on developers who can focus on implementations to meet functionality.

 In my experience working as Architect for vendors, I find above strategies very effective. Value realization in outsourcing would be high when the quality of delivery is good with respect to implementations. Most vendors try to maximize efforts, focus to improve good perception of engagement, lead customers team to be in comfortable zone, but take a relaxed approach to quality of deliveries. It is for customers to build framework for performance evaluation to keep vendors on toes. Adopting above practices will benefit both customers and vendors to realize win-win relationship. At the same time vendors need to respect people skills and adopt people centric policies to have consistent results. Eventually these strategies have potential to be strategic competitive advantage.

I do invite comments on the topic..

Java Framework for Batch Applications

Batch applications are most common in the enterprises today. They seem to have a role even in the modern enteprise landscape, probably because it represents real-life nature of work we do in organizations. For e.g. we do end-of-day processing of checques, scheduled processing of orders, settlement of bills in hotels done at the end of day. Hence the relevance of batch frameworks will remain in advanced landscape too. Typically looking at the enterprise milieu, there are many scenarios that demand once a day processing or even less frequency of processing in a day. For e.g.
1. Report generation for management information,
2. Database synchronization at the end of the day,
3. Extraction of report information for industry feed etc.
 May be the way it is applied can change. Many legacy systems and mainframes process information in a batch model to handle work-loads efficiently.

In enteprises, there could be different mechanism to handle batch processing. Typically ETL tools are using in a sourc-to-target information exchange that includes translation and data-quality needs. These tools provide out-of-box features to manage transformation needs. But, there are also simple programs that are scheduled to run at specific intervals to handle batch processing needed. For e.g.
1. Standalone Java programs scheduled on Unix with Autosys or Unix scheduler
2. Standalone Unix shell scripts that are run on the Unix server periodically.
3. Database stored procedures that produces flat files for report generation. They could be efficient in data-synchronization, being close to the target data store.

Lets look at the important capabilities needed in a batch applications:
1. Ability to process large files within available window time,
2. Ability to handle files or information in different formats,
3. Process information in parallel and multi-threaded models.
4. Be flexible and extendible to accomodate customized transfromation, persistence and conversion logic,
5. Persist meta-data to enable auditing, monitoring and management.
6. Ablility to provide sync-point to enable restart
7. Handle data errors and exceptions gracefully,
9. Support remote monitoring, administration and manageability.
10. Support testing of batch models in modular fashion.

Developing a custom batch program to the needs of the project is always the option, but having a consistent model and framework to build batch programs would benefit the organization immensely in the long term. Well, open-source frameworks are maturing today to fill this space with the enterprise. One among them is Spring Batch 2.x framework that is matured enough to be used in enterprise landscape.

Spring batch framework is excellent framework for batch processing framework for system. It provides excellent abstractions to represent batch model of processing in a easy, understandable, modular and reusable fashion. With its latest version Spring Batch 2.x, it has built good capabilities that makes it top ten open source frameworks that are worth using in the enterprise landscape.

Following are positive features to adopt Spring batch framework:
1. It clearly defines separate layers: Infrastructure, Batch Core and Application, with abstractions that are extensible, reusable and testable.
2. Being part of Spring family, it maintains all benefits of using Spring with extended capabilities
3. Provides support for batch state and meta-data persistence that helps in monitoring and restartability.
4. Out-of-box support for variety of ItemReaders, ItemWriters and Tasklets
5. Support for different scalability models : Single process - multithreaded, Partition - Multiprocess - remote processing,
6. Well defined xml based domain language for batch applications that support dependency injection, customization and reuse.
7. Batch data model that supports meta-data persistence and monitoring.
8. Restartability, ability to restart processing from the next data-item from the source. This adds to the resilience of the solution, the much desired features.
9. Variety of job launching options, Command line program launch, programatic launch on message arrival or event.
10. Monitoring and Management of batch jobs for job operator. This supports realtime monitoring.

Spring batch projects applied in following scenarios:

1. Scheduled report generations: Producing end-of-day management reports on a operational data store. Integration with report engine and source data store.
2. Reference data update : Fetching and updating reference data on reference store periodically. XML being data exchange format, processing xml elements as data items.
3. Partitioned event based processing: Batch jobs launched on arrival of messages. In a partitioned and staged design, processing is partioned in stages. This provides resilience and restartability while processing large files.

There are few cases where one needs to extend the support provided in the framework, it is very flexible, being Pojo based, leveraging capabilities from Spring family with AOP, Config, Integration and Context management, it is powerful framework and has wide applicability.

We could see following benefits in using this framework:

1. Reduce risk for the project, due to use of right framework for the job, it  reduces chances of going the wrong path.
2. Reduce time to delivery, due to support at Infrastructure and batch domain abstraction, providing out-of-box reuse of capabilities
3. Large active community base, supports product adoption, enhancement and shared learning.
4. A much needed standard model for batch processing within enterprise that helps reuse, reduced effort to maintain, extensible and provides longer life to the application.
5. Being open-source, reduces cost of adoption, no licensing cost.

Some of the features that could be added to this framework are:

1. Distributed and remote monitoring and management of Batch applications in centralized fashion.
2. Enhanced support for execution environments -  Hadoop and SEDA model,
3. Flexibility in applying multi-threaded processing within a Step.
4. Remote Administration.

It has wide applications provided we leverage its abstraction model and comply with rules of usage with respect to scalability and persistence. Following resources are useful for readers:

Batch processing strategies
Scaling with Grid

Anti-pattern - Using ESB or Integration Broker as Application platform

SOA style of architecture is being adopted gradually by the industry. Organizations have started to view their business capabilities as set of well managed Services that are modular and reusable in different business processes. Business is slowly realizing the value of SOA with respect to Reuse, Business-IT alignment, and Agility.

Product vendors have responded swiftly by introducing SOA enabling products that help expedite the adoption process. There are many ESB & Broker products introduced that are expected to introduce loose coupling by placing intermediary that handles integration concerns between business applications.

Some of the commercial products are:
 1. IBM WebSphere Message Broker, Websphere ESB, WebSphere MQ.
 2. TIBCO Businessworks,
 3. Webmethods Broker, Integration Server,
 4. Oracle Service Bus
5. Sonic ESB, etc

Apart from the commercial products there are open source products and lightweight frameworks that can do the role of ESB's for e.g Mule, Service mix, etc.

Often, I have seen many organizations using the ESB or Integration platforms as Application platforms. This means they use them to build business applications that produces and consumes inter-application messages. This is to me an anti-pattern where Integration platforms are loaded with business logic, complex persistence flows and business decisions. It is a kind of bad-smell in the design of the system and usage. I see following dis-advantages in using this model.

1. The purpose of ESB's is to be an integration middleware, de-coupling producer and consumer applications in many ways.
2. ESB's help induce seperation of concern between Integration-logic and Business-logic. All integration logic is isolated in Integration environment, so that if it changes the change is limited to Integration platform and not applications.
3. ESB's are appropriate for connectivity, translations, enrichment's and  validations in the context message processing. When we start putting applications and business logic inside ESB, then it starts smelling and add more complexity to manage.
4. Most commercial vendors provide message flow framework to write mediators. Sequencing of activities within mediators creates a message processing flow. The flow is created to link the source application to the target application. Adding business logic, entity persistence, rules and decisions, controlling application logic in flows will defeat the purpose of seperation of concerns. Hence it increases rigidity and complexity of applications.
5. ESB's are not made to write applications, where applications need complex persistence mechanism, caching support, data-structure support and other application frameworks.
6. Business applications are best written in good object oriented languages, leveraging application frameworks, containers, management tools etc. For e.g. building order processing engines on Broker or ESB is not good idea as it is defeating ESB's purpose, and not leveraging application frameworks.
7. Applications are best written in OO platforms or frameworks like the Java, dotNet, Ruby on Rails etc.. and deployed on Application Servers like Websphere Application Server, JBoss, Tomcat, etc. The advantages of using OO is huge when written in good abstracted manner, resulting in well defined, modular, maintainable, reusable & component based applications.

I have often seen organizations that use Broker platforms to write applications that processes messages but also host business logic, business entity and persistence of business entities. I find this as  anti-pattern. Probable reasons they take this decision are:

1. Immaturity of decision making,
2. Organizations do not spend efforts in evaluation of architectural and platform decisions.
3. Not enough understanding and appreciation of Object oriented platforms.
4. Ivory tower architects making decisions without practical experience on platforms.
5. Not enough experience on Agile, Object oriented principles and processes.
6. Not enough clarity on usage of architectural styles and their fitment.

I would recommend reading following articles to understand fundamentals of ESB style of architecture.

Mark Richards on ESB
Fundamentals of ESB

I do welcome comments on this topic, please write your thoughts..