Building the team

Suppose you're a manager tasked with building (or buying) and implementing a payment system (whether from scratch or an add-on).  In reading this post, there's a chance that a jPOS-based approach is going to be in your selection set.  If so, as a manager, you'd want to construct a team that's going to maximize your chances at success.

I asked a question like that to Alejandro at one point: what are the critical skills that team members should have in order to succeed at a jPOS-based project?  Here's the list he came up with, in order of importance (I've added some additional commentary and tacked an additional item on to the list)

1. Object-Oriented Programming - This may seem obvious to some, but not to many others, so bear with me here.  Fact is, if you come from a legacy application background (like if you've been writing code for BASE/24 or ON/2 - two legacy payment system offerings - for the past 20 years), the jPOS approach is going to spin your head.  What's doing the spinning isn't the payment systems concepts as those really don't change over the years, but rather its the object-oriented approach to the system construction.  It's a completely different mindset and approach to coding.  Your team members need to understand it in their blood and veins.  Your urgent, time-bound and budget-constrained project may not be the opportune time to introduce O-O to your key team members.  The good news is that with O-O knowledge comfortably in hand, the rest of the list is definitely attainable in a reasonable timeframe. 
   

2. Java - jPOS is written in Java. Enough said.

3. Open Systems Projects - As Alejandro says, there's a way of working in the Open Systems world...a repeatable model that all projects of this nature use starting with downloadable software and documentation, but then (importantly) extending to such elements as mailing lists, blogs, bulletin boards, FAQs, etc.  A good team member will know how to maximize these resources.  Like, for instance, in the jPOS world there are two really good mailing lists that can connect your team members to a worldwide repository of jPOS knowledge.

4. Hibernate - Hibernate is a powerful, high performance object/relational persistence and query service for Java.  The following passage from Hibernate discusses the reasons why Hibernate is a good solution for the Java application developer and why it is a key part of the jPOS solution: 

   Working with both object-oriented software and relational databases can be cumbersome and time consuming in today’s enterprise environments.  Moreover, development costs are significantly higher due to a paradigm mismatch between how data is represented in objects versus relational databases.  Many software developers and architects estimate that up to 30% of their code is needed to deal with this infrastructure concern.  Hibernate is an object/relational mapping (ORM) solution for Java applications that directly addresses this challenge by providing the ability to map an object model’s data representation to a relational data model and its corresponding database schema...Hibernate is the most flexible and powerful ORM solution on the market today. Hibernate not only takes care of the mapping from Java classes to database tables and from Java data types to SQL data types, but also provides data query and retrieval facilities that significantly reduce development time.  Hibernate’s design goal is to relieve the developer from 95% of common data persistence related programming tasks by eliminating the need for manual, hand-crafted data processing using SQL and JDBC.

5. jPOS - Now (with that basis), your team can tackle jPOS.  I’ll direct you to two pages – What is jPOS? and Buy vs. Build.  I think this paragraph (from the first posting) specifically gets to the heart of jPOS - "jPOS can help you act as acquirer or issuer, can be strict one-to-one or one-to-many, can do passthrough processing or act as host. Not inherently, mind you. You and your team would need to build that capability on top of the jPOS framework, which does not inhibit you in anyway from any of those directions. The 'zing' you get from jPOS is that it eliminates most of the grunt work associated with complex ISO8583 messaging implementations and its corresponding security requirements, thus allowing you and your team to focus on more 'value added' activities. Your marketing and sales team don't know/care about your work on ISO8583...they simply care about whether you can support new card products and/or features, new devices, new points of origination. A jPOS framework allows you to reorder work to focus on customer-focused activities like that.

Now, I added this item:

• SQL - jPOS is SQL-based.  A team member who knows SQL can be an immediate and important contributor to the project.  I've laid out the importance of that knowledge in a previous post called Thoughts on jPOS and SQL Databases.

Comments

[The Jaywalker]

Nice. Keep posting!