December, 2009

In-box SCA with Spring for home-made CRM

Wednesday, December 30th, 2009

It’s a know fact that CRM roll-out may cost twice or even thrice more than CRM solution to be implemented. Even worse the chance to fail is very high, unless you create a detailed program of implementation and invite integrators with a good reputation (that will not give a 100% chance of success though). Generally, pains of CRM implementation resemble the pains of BPM roll-out. In case of BPM, risks may be decreased with building the value up step-by-step and implementing “behind the scene” initiatives. In case of CRM it’s generally counted as not a very good practice (however IBM Global Service uses this approach), but until concepts and benefits of CRM are understood thoroughly, quick wins achieved by “denormalized” CRM components (that normally cover one process or just a part of it, whereas leading CRM products may be adjusted to any process of a company more or less painlessly) can be a good start.

Path of stepped roll-out is usually taken by the companies that don’t have much experience in CRM (and probably tied to ERP system that they want to extend with CRM features). With the means of their own development department (or delegating development to the offshore/nearshore) they sequentially, with small steps, cover different areas of CRM (mostly operational) with the components that offer the clearest ROI. Home-made CRM solutions have the following disadvantages among the others:

  • single solutions introduce a lot of code duplication;
  • architecture is not flexible and changing requirements may be crucial, as those applications are mostly developed in a very short time frame under the pressing of marketing or sales departments (value and behavior comes first);
  • maintenance is painful as quantity of spaghetti-code grows over time;

At the same time, it’s hard to predict, which area of the solution under development requires the highest flexibility, and making all parts of the system too generic and flexible can also add complexity to design and affect performance (generic solutions that, say, may work with different databases will never work as fast as those that uses all tricks of a specific database). Another point is the human factor – if you leave developer alone with the program, it will definitely create another framework.

Solution of my choice that can address all the mentioned problems and requirements is Service Component Model (aka Service Component Architecture). Key concepts of SCA are:

  • service (also called “asset”) – independent reusable functionality;
  • component – composition of services (1+ services) that address a particular horizontal (technical) or vertical (business, domain) problem;
  • assembly – complete system assembled of independent components and assets;
  • orchestration and choreography – define behavior and ways of communication within assembly;
  • event – way of intercommunication;
  • storage – single place where assets (components) are stored to reuse lately;

Many specialists think of SCA (and SOA) as the equivalent to implementation of WS-*. WS-* stack certainly has the most technologies to realize SCA (WSDL, UDDI, SOAP, WS-BPEL, WS-CDL), but conceptually, complete SCA can be achieved with REST, CORBA, while in-box (or better say in-container) SCA may be implemented with Spring Framework. Dependency Injection paradigm (used for orchestration and choreography) keeps assets decoupled, and defines relationships between assets in components and content of the assemblies. System availability may be later achieved with REST-services (over service interfaces) and Spring Integration engine.

(more…)

Tags: , , , ,
Posted in Software Development | 3 Comments »

3 practical advices to survive on the maintenance project

Saturday, December 26th, 2009

     Unless you’re not a natural born maintenance engineer and your main target of the life is helping clients of your company (I’m not sarcastic here – I do believe this branch of development is very important and I respect those guys who support for years systems written in COBOL in early ‘80 for their great patience), maintenance is a burden, and your first thought every morning is how to survive this hell. I understand your feelings, as I’ve spend almost 3 years for this nasty activity in the beginning of my career. If you’re a green horn in development, this kind of experience may be useful for you (getting expert in, at least, some technologies; learning business processes of your company; having fun chatting with the customers),  but if you’re dreaming about software architect position and have grown from your pants, maintenance may be really stressful. To keep your brains from being atrophied (and survive on the maintenance project for the better times) you may follow three simple rules that helped me and some of my depressed colleagues forced to maintain legacy code:

-         Don’t spend more then 70% of the day on routine. It’s already a proven fact that statistically you’re not spending more then 6.2 hours per day effectively (so called “in the flow”). If you’re involved in a hardcore maintenance, sometimes it seems like number of bugs in your bug-tracker is infinite, and when you close one, 2 new ones appear there instead. Concentrate on bug-fixing  for 5-6 hours per day (depending on priority of the opened bugs), and spend the rest of time on analytics and self-education. Automate everything (use continuous integration tools, static code analysis checkers, hand-made scripts, etc.), but be ready that your working day will be longer. You may be sure, you boss will commit to this kind of time investments – you mental health and up-to-date knowledge are the most important during the marathon;

-         Read you favorite blogs everyday at least 30 minutes per day to be connected (better 1 hour), listen to technical podcasts in your mp3 player on the way home (work) and spend not less then 1 hour at home for reading books. My personal preference is to read technical/management blogs at work and domain-dedicated books at home (normal velocity is 1 book in two weeks). “Vertical” understanding of the development process is very important. If the pressure at work is too high (say, last week before going live) it’s acceptable to stop reading for some time, but the first free week I prefer to spend 1 day for looking through all the posts I’ve missed. Spend as much time for reading as possible – always have a book with you to read when you travel, wait for a queue in the bank or any other situation when you’re idle;

-         Have as much practical experience during the working hours as possible. Even if you’re tied to any particular platform or technology and it’s not possible to introduce something fresh and trendy in the system you’re maintaining/developing (enterprise giants are often built on their own home-made frameworks, using legacy approaches to architecture, etc.), you still have a wonderful opportunity to practice new technologies during your working hours outside of the product you ship. To train new approaches I’m writing scripts for automation, installation and migration on Groovy and Ruby, internal wiki’s and support portals with OSGi/REST, etc.;

Tags: , , ,
Posted in Software Development | 3 Comments »

Getting started with CRM

Friday, December 18th, 2009
     CRM (customer relationship management) – strategic client-centric direction of the business, on the foreground intended to build reach customer experience of collaboration with the company (in the modern CRM “customer” can be a client, a partner, a supplier or an employee) on the basis of interaction history and analytics produced by Customer Intelligence processes, and on the background, increasing customer lifecycle value, decreasing costs, giving opportunities for up- and cross-selling, etc. (it’s my personal understanding – you can find hundreds of other interpretation on the internet).

     I’ll be honest with you, during my early days at Hyperion I wasn’t too much concerned about the “domain”. Firstly, because of the nature of the system we’ve been developing – half enterprise-scale CMS system, half huge enterprise integration bus for all Hyperion products. It didn’t require too much understanding of the business background, because most of the aspects and pains of that system were purely technical (building a scalable and durable SOA that can integrate a plethora of the other system that were stand-alone before the moment, creating a friendly interface to command all those systems, etc.). The second reason was business analysts that could always clearly and throughoughtly explain what should be done here and there, so that business requirements didn’t change too much during the development.

     Everything sounds good so far, until it comes to adding more real value to the system. I do remember the day, when my manager came to the team, and asked about building a list of things we want to change in the system to make it better and more attractive for the customers. And every single person from the team (me either) added to the list only the points regarding a technical side (cache improvements, change in the persistent layer, etc.). Well, unless the chief financial officer of the company you want to sell your solution to has an IT education, it’s incredibly hard to use “cache improvements” as an argument of the increased ROI :) . This blind approach to development brought us to the following points:

  • We couldn’t introduce an innovation;
  • We couldn’t critically review business requirements and argue about them;
  • Level of commitment was low;

     Nearly at that time I had a chance to read a brilliant inspiring book “Domain Driven Design Quickly” by Eric Evans explaining an importance to understand the background of complex domains deeply, that gave me a clear direction for the next projects.

     So, when I started my path in the NDC of O2’s CRM/CI department I was open-minded and all about not making the same mistakes again – now, on the daily basis I’m gathering information not only about technical aspects of development, but also concerning the business aspect.  Several books and dozens of articles + one designed and implemented system later my recommendations to get started with CRM are following:

  • You must read an amazing book “Business Process Management: Practical Guidelines to Successful Implementations” by John Jeston and Johan Nelis. It’s not the easy stuff to start with (especially, if you’re very new to the business domain), but your own personal ROI after reading this book will be huge. “BPM” written as a guideline/overview to start practicing BPM in the company (so target audience is actually a high level management) and gives a clear understanding of the business process nature of modern enterprises. For me personally almost every single page was a kind of a revelation;
  • The second very important reading is “CRM at the Speed of Light” by Paul Greenberg. This book not only explains in details all the areas of modern CRM (CRM metrics, sales and marketing automation, partners management, etc.), but also gives an overview of the CRM solutions for all sizes of businesses that exist in the market. I personally respect this guy because he’s a great example of a person who has a deep knowledge about the business and IT in order to get as much juice as possible from the both areas.  For instance, in one of his recent posts in the blog he explains benefits of using the lightweight RESTful architecture in enterprises – I can hardly believe, our local business analysts know something about the REST at all (not talking about benefits in compare to WS-*);
  • Finally, you should start following the blog of “CRM Magazine”/ reading “CRM Magazine” itself – I believe, the most influential source about CRM that you could ever find;

     These point are the most crucial to go. At least, you will understand the business requirements clearer (and there will be no unknown buzzwords for you anymore), in practice you’ll be able to argue about them, give your concerns and introduce innovations that have a real business value.

Tags: , , ,
Posted in Software Development | 2 Comments »