ultimately we want the bank to own its software, based on the LAMP stack (Linux, Apache, MySQL, PHP/Perl/Ruby), with some variety of open-source license
4. IT team research and recommend an existing development framework for the custom software. What are the sensible choices and which is best for us? Consider at least Kuali RICE and Ruby on Rails.
5. For each hardware and software component recommend: buy/rent it/get it donated? (if so, what product?) make it? (if so, what's the design?)
6. In collaboration with the project's Steering Committee set a feasible development timeline.
7. Write a comprehensive CGB IT outline understandable by regulators, non-IT staff, and well-educated public, including diagrams showing how the IT components interrelate. Use Kurt's 2009 CGB IT Plan Outline 1.0 as a first draft.
8. IT team recommend criteria for hiring IT personnel for the development stage.
9. CGF Steering Committee decide (with IT team) how to compensate IT personnel: up front? with shares of stock? In-kind donations of labor will be welcomed but not expected.
10. CGF management recruit, select and hire personnel (most likely including members of the original planning team).
IT team please comment. Comments about Kurt's IT Plan Outline should go on the IT Design page instead.
We want to get our initial team together and complete our discussion on this proposed IT Strategy no later than Saturday June 19 so we can get moving on it ASAP!
All of these but the last use Java, most use Java EE. The first two (Mifos and Kuali) are closest to where we want to go. Both use the Spring framework. Mifos is a micro-finance banking solution developed by the Grameen Foundation. Kuali was developed by a consortium of universities for use in higher education.
If you are a Java/EE software engineer with experience using the Spring framework, join us! Contact us at info@commongoodbank.com.
… I believe CGB would be best served by having a Plan B (the backup plan) and some folks working on that, sooner rather than later.
Some one or two committed people who become knowledgeable about proprietary banking software, create a short list, develop an RFP, send it out and ask for full demonstrations. Obviously doing Plan B will serve Plan A. It sets a cost benchmark (amortized at say, 30 years). It also puts working software before our eyes. Often times a software company will put a fully working limited license package in a potential clients hands. That in my mind would be ideal – a "best case" system to reverse engineer, which then becomes the default Plan A, lacking sufficient organizational oomph to do the necessary engineering work. Doesn't mean the team quits, just means building more time & people into the equation to make it happen, without postponing a CG bank opening.
I propose that we proceed to ascertain the truth of that possibility and not bother with a survey of off-the-shelf solutions unless and until we discover that an open source solution is impractical. Yes? Please comment.
No, I don't think its a good idea to not have a Plan B. Plan A – The open-source plan to adopt & modify an existing ERP/web application framework – OK, that' what I'm doing and advocating, and I appreciate your support for it. However, I believe CGB would be best served by having a Plan B (the backup plan) and some folks working on that, sooner rather than latter.
Some one or two committed people who become knowledgeable about proprietary banking software, create a short list, develop an RFP, send it out and ask for full demonstrations. Obviously doing Plan B will serve Plan A. It sets a cost benchmark (amortized at say, 30 years). It also puts working software before our eyes. Often times a software company will put a fully working limited license package in a potential clients hands. That in my mind would be ideal – a "best case" system to reverse engineer, which then becomes the default Plan A, lacking sufficient organizational oomph to do the necessary engineering work. Doesn't mean the team quits, just means building more time & people into the equation to make it happen, without postponing a CG bank openning.
I have become convinced that we want to create our own open source solution if we can do that in a reasonable amount of time (less than 18 months) and at a reasonable cost (less than $1,000,000)… It seems plausible, at a first look, that the available open source enterprise accounting software is sufficiently advanced that we CAN in fact create an open source solution in the required timeframe and at a reasonable cost…
This would reduce #5 in our IT Strategy to "What's the design?
Every company wants to reduce risk and uncertainty. I have sometimes heard of bankers being referred to as "risk reduction specialists." Any one loan can fail, but statistically, a pool of loans will display trending to the median, and so predictability, to which the "cost" of that risk can be applied through set interest rates. Unless of course, its the market as a whole that fails, and we end up with a financial crisis. So bankers, in their zeal to avoid risk, building abstractions like "credit default swaps" so complex they no longer have any way of determining the real risks, and thereby precipitating the very crisis that undermines our market based economy. But this isn't a commentary on the crisis … its about what "we" do to avoid risks, as people, as well as the "risks" we choose to focus on.
By "open-source" we mean a whole philosophy that says complete code transparency is a way of reducing the risk that code will operate in an aberrant way. Closed source means a very limited number of people get to see, or change it. Just like bankers trying to avoid risks ending up with the opposite, and failing. But the phenomena of open-source is much more than that, of course. What has happened is more like a revolution, a social phenomena that changes everything. Because it has humanized the field of software development. And bankers, developers and technicians, are after all, just people. We can't help but act as people do, wanting as has been often said "to have the experience of being truly valued." Bankers may take the measure of that as salary, but money ain't everything.
The primary risk I'd like to define for the Common Good Movement (bank as revolution) is the risk of exclusion and the risk of non-collaboration, so wanting to error well on the other side of inclusion and collaboration. My suggestion of Kuali, is a suggestion for: a> a well researched set of development standards and best practices, b> a web application framework fully aligned with mainstream open source methodologies and c> a demonstration of agile programming methodologies at work. How much of the kuali code base gets included in what we eventually roll out as our open-source banking solution, has yet to be determined. But its development standards and best practices are a sine-qua-non, starting with agile methods.
Part of the Manifesto for Agile Software Development is this understanding of inclusivity, cooperation and collaboration. Our open-source banking solution can & will succeed only to the degree that it involves everyone in the bank. Significant contributions can come from anywhere, and not necessarily only from the technically trained. I also believe in good design, so asking that foremost question "What is the design?" See my previous post about http://xuse.sourceforge.net/, using an open-source design tool for that necessary achievement. There's no question that it can be done, only the questions will it be done, by whom, and for what purpose? The outstanding question of costs doing it are far out-weighed by the question of not doing it. Then making a commitment to start well, doing it well, and completing
Through conversations with Richard Kerver, I have become convinced that we want to create our own open source solution if we can do that in a reasonable amount of time (less than 18 months) and at a reasonable cost (less than $1,000,000). Here's why:
If we START with off-the-shelf software (whether bought, rented, or donated), then we are forced to adapt our activities to that software and, implicitly, to the assumptions underlying that software. Those assumption would necessarily include a banking paradigm that is tightly controlled from the top down, opaque, and uncollaborative. We would be progressively investing more and more time into learning, working with, and adapting to that software, developing a dependency on that software and set of assumptions that would be harder and harder to shake off.
We want to avoid that dependency like the plague.
Less importantly, owning our software will deeply reduce the bank's monthly operating costs, thereby increasing our chances of overwhelming success.
It seems plausible, at a first look, that the available open source enterprise accounting software is sufficiently advanced that we CAN in fact create an open source solution in the required timeframe and at a reasonable cost.
I propose that we proceed to ascertain the truth of that possibility and not bother with a survey of off-the-shelf solutions unless and until we discover that an open source solution is impractical. Yes? This would reduce #5 in our IT Strategy to "What's the design? and How many person-hours will it take?", which we need not consider in detail until we have chosen a development platform.
Hi – after replying to William's email, he suggested I post this info to the forum, so here it is. I have sent William my resume.
1. Do you want to be involved in this project in the planning phase (yes, no, or maybe) and/or
The objectives in the planning phase are probably outside the scope of my areas of expertise, but if, after assessing my skill set, you think I could offer any help, let me know.
2. in the development phase (yes, no, or maybe).
I have experience in crafting user interfaces that are user-friendly and intuitive. If that falls within the development stage, then yes.
3. Please also estimate how many hours per week you would like to participate, and in what months.
November and December are challenging in which to find time, the rest is possible
I think I could offer a few hours a week.
4. Tell us what are your specific areas of experience and expertise (send us a resume if you have one).
My specific areas of experience and expertise are with databases and database design for small non- and not-for-profits. My work has been mostly in small databases (dBase, Paradox, FoxPro, Access), but I have recently had training and some experience with MS SQL backend databases. I have experience both building from scratch and customizing out-of-the-box programs. My strengths are in analyzing the data-collection needs based on the required data outputs, as well as looking at the data-collection interface from the user’s point of view. I also have strong communication and writing skills, which, when coupled with a diligence in attention to fine details, have been used with great success in creating user instruction manuals and technical documentation.
I have to ask the question whether out of the gate, the online platform is what will distinguish the CGB and be a key element of the "brand"
Good point. I think the answer is probably no. So we should definitely consider starting with off-the-shelf online software, if that will do the trick for now. Our marketing team will have to weigh in on this too.
there may be some both appropriate and socially minded vendors who might wish to offer their banking platform to CGB at a deeply discounted rate
Another good point. To emphasize and remind us of this possibility I have added it to the proposed strategic plan, step 5.
Jesse Seaver said "is there any budget to have this brand developed?"
The IT planning phase will include pricing various options and recommending a path forward. This will necessarily result in a figure for IT development budget. I expect that the development phase AND the marketing phase will both be comfortably funded. The planning phase will probably not be funded.
We have another group strategizing marketing and how to find whatever funding we need. Our responsibility in the IT group is to find a great solution at a reasonable price (and ideally at a bargain price).
There will be some overlap between the IT planning and the Marketing/Funding planning. Notably in UI/UX design. I think we will simply need some members of both groups to work together on areas of overlap.
To speak to the UI/UX importance for a moment – I feel that the design and general identity of a service, or brand, is paramount to almost anything else. The quality of goods, services, and standards that are associated with your industry will be be assumed high quality by the consumer – the real differentiators will be the design of the program. This means everything, from the initial ad they click on or flyer they see, to the site login, to the look of the ATM card. Both in content and in design, the offer must be appealing to the senses of your potential customers. A limited design will radically take away from the extensive knowledge, information, and innovation that is being offered by CGB.
In many ways, if you do not nail the design, you will waste the engine behind it.
So – to relate this to CGB – I am going to bank with you not because I think you will earn me xx% or because my ATM card will work everywhere (utility) – I assume that. I will bank with you because it makes me feel good to know I am part of your program, and because it makes me feel good when I see your brand (design).
Jesse, I couldn't agree with you more about the importance of good design. In my mind, this extends also to the internal users of a software system, the people who will ultimately drive the success of the CG Bank. Banking operations, throughout the organization, inclusive of both customers and employees, and the workflow that ties everyone together, if done well will not only attract new customers, but help retain employees.
Both William and and I are advocates of OpenSource software systems for a number of reasons, including the rich set of tools available from the larger community of software engineers. Many of the brightest engineers work for and/or with various OpenSource projects. As engineers, they often invest in tools for themselves, from code management, to issues tracking, to UML modeling and software design.
The requirements process is fraught with danger from both a customer and supplier perspective: it is a widely held view that the majority of failed IT projects did so because of poorly conceived, badly managed or inadequately documented requirements.
The selection of inappropriate tools to "aid" with the requirements process only serves to compound the problem: many requirements tools seem to be over complicated providing feature rich implementations that have become so bloated that they have lost focus on the primary task of requirements capture: communication.
It is here that Xuse aims to make an impression: Requirement Zero for Xuse stipulates that "Xuse shall – above all else – focus on delivering a toolset that allows for effective communication of requirements between all the stakeholders.
The great advantage of taking ownership of the banking software from day one includes control over the design and ultimately the set of deliverables. It opens up the possibility of doing all the branding you suggest, providing a unique and powerful interface (UI-UX) that differentiates the CG Bank from all others. If not aiming for that uniqueness, if CG Banks were just another bank like any other, then why do it at all?
I have reviewed the strategic plan you sent. I feel that where I may be
able to assist you most is in your User Interface / User Experience
planning. Unfortunately, I am already committed to my current project
for the majority of my volunteer time. However, I have always wanted to
help make
this happen, and would still like to propose a UI/UX scope and design layout suggestion.
I am curious, is there any budget to have this brand developed? Aside
from the UI/UX, there needs to be significant time invested in the
marketing message, the channels of communication, the overall ID
development, market research, possible market list purchases, etc. My
hope is that you do have a budget for some of this, because I have found
it almost impossible to develop a full marketing, or IT, campaign
without the resource of some essential services – such as Google
AdWords as a minimum.
To speak to the UI/UX importance for a moment – I feel that the design
and general identity of a service, or
brand, is paramount to almost anything else. The quality of goods,
services, and standards that are associated with your industry will be
be assumed high quality by the consumer – the real differentiators will
be the design of the program. This means everything, from the initial ad
they click on or flyer they see, to the site login, to the look of the
ATM card. Both in content and in design, the offer
must be appealing to the senses of your potential customers. A limited
design will radically take away from the extensive knowledge,
information, and innovation that is being offered by CGB. In many ways,
if you do not nail the design, you will waste the engine behind it. As a
rudimentary example of what I mean and how important design is – when I
purchase a chair, I assume that it will all stay together when I sit on
it – and as I test them all out at the store they all do. I don't
decide which chair to buy based on which one doesn't break (utility) ,
none of them
break. I decide to buy based off 1) how the chair feels when I sit in it
(ergonomic design), and 2) the way it looks (visual design) .
So – to relate
this to CGB – I am going to bank with you not because I think you will
earn me xx% or because my ATM card will work everywhere (utility) – I
assume that.
I will bank with you because it makes me feel good to know I am part of
your program, and because it makes me feel good when I see your brand
(design) .
I
look forward to hearing from you and your team, and again, I hope that
beyond the initial volunteer scope of time that is required to get this
started, that serious budget consideration is being given to ID
development, strategy, and an overall 5 year marketing plan.
I am more
of a developer than an IT person. I read through the IT plan. The data
modeling I understand very well. The auditing, I do not have a clue.
I do not think I have much to offer at this stage. I would still like
to help with the development when the time comes. I know that the Rails
framework is being considered. I have not used this but I could still
help with the front end. If it is a php,.net or java framework, I could
help on the back end also.
Admittedly I have only scanned the IT plan and the good suggestions posted so far, but after a conversation with William he asked that I share my inisights.
1) My guess is that there is enough work with organizing, developing, refining charter and mobilizing the community around CGB without getting too bogged down on IT platform customizaton and development. Or bug fixing.
2) Although I agree that a special platform is probably needed, I have to ask the question whether out of the gate, the online platform is what will distinguish the CGB and be a key element of the "brand". Is it functionality of the online banking features, or look and feel that's important? Is it what you can do, or how it looks and feels as you do it? My sense is that CGB a "normal" bank with standard banking features, but governed differently and with a different profit motive. It's still a bank.
3) I assume that there are several standard platforms out there for banking. I also assume that amongst these platforms, there may be some both appropriate and socially minded vendors who might wish to offer their banking platform to CGB at a deeply discounted rate, for the PR, for the tax break, or simply because they are socially conscious.
I think researching banking platforms (esp. credit unions) and approaching several of these vendors might be a very good idea.
.. I volunteered to work on this project, but after reading the contributions of the other volunteers, I realized I did not have the IT expertise the project needed…question I have is how affordable would it be for CGF to acquire its own bank software right from the start….
Neige, thanks for your kind thoughts and questions. I believe there is a very significant leg up with Kuali and has potential, so much so that I've committed to instantiating it on my machine. Your questions about experience, costs and so forth are appropriate for CGB's planning stage, and I hope to answer those questions. I feel the answers are in demonstration rather than guessing, in proof-of-concept rather than speculation. There is no "cost" to me except the investment of time. Kuali is available under a free & open source license. Unlike your typical desktop FOSS application, like OpenOffice, there is some difficulty in the undertaking, however. We're talking about enterprise class software after all, of the sort that drives Amazon.com, for instance. Nonetheless I'll persevere until such a time as I've proved its either within or beyond my own expertise.
With regards to the vision thing – we have lots of enterprises that are amazingly successful today because they first invested in their web application, and Amazon.com tops that list – see Amazon.com Tops Rankings of Healthiest Retailers. I can't imagine that in the early conception days of Amazon, those entrepreneurs saying, 'well we need a warehouse, or we need inventory, or … whatever.' No, the vision was for an on-line retailer served by the web. The web application was the enterprise and success/failure would occur only to the degree their "geeks," to use a phrase, delivered on that vision. By the way, Amazon.com is built using Java EE, and the Kuali team did the hard research before engineering their systems, the same way. As a matter of fact, most all on-line banking systems are built with Java EE, again because they have knowledgeable and informed "geeks" involved.
We're talking about not just another on-line bank, however, but one with radically new business rules. I think of it as social networking meets on-line banking, what William says is "a movement that owns a bank." It could be any movement, small family farmers, for instance (see this.) The beauty of the CGB vision is that once it gets rolling, it could be any local group anywhere helping remake their communities with the money that makes the magic happen. In geekland fashion, its called replication, and the computer platform is the "cloud." Making it happen will take more than just a few, however. If there are any IT people who believe in the CGB vision, and a brand new web application that can deliver that vision, and want to
share in this undertaking, I'm more than willing to share my experience.
Hi Richard, I am Neige, and last year I volunteered to work on this project, but after reading the contributions of the other volunteers, I realized I did not have the IT expertise the project needed. The little I know though tells me your process recommendations are right on. One question I have is how affordable would it be for CGF to acquire its own bank software right from the start. Also, besides William's three things we need list, I believe your points below were very well made:
First steps would be to form a core IT team. The core IT team should first research, agree and write-up recommendations for an application development framework
A web application development framework should be adopted rather than be developed, maximizing code reuse from the open source community
The idea is to get a CGB started on a well designed financial system and then, using open source development methodologies, to branch the project so that it most efficiently and more specifically meets the needs of CGBs. Ultimately the success/failure of an IT project is dependent on a stream of technically competent people, over time, coding to open standards. There is a greater likelihood of succeeding through alignment with a broad open source community, such as is behind Kuali.
ultimately we want the bank to own its software, based on the LAMP stack (Linux, Apache, MySQL, PHP/Perl/Ruby), with some variety of open-source license
4. IT team research and recommend an existing development framework for the custom software. What are the sensible choices and which is best for us? Consider at least Kuali RICE and Ruby on Rails.
5. For each hardware and software component recommend: buy/rent it? (if so, what product?) make it? (if so, what's the design?)
<snip>
Most of the items seem well thought and clear – especially the ground rules summary in #3.
#4: Looking at http://www.kuali.org/rice
and http://rubyonrails.org/ the site orientations are
very different: KR is
geeky by describing it as middleware – a rich set of which we will need
to create a robust, secure application and its components. On the
other hand, the RoR page seems to suggest that someone may have already
built a bank with it. If so that could save us a lot of work. But do
any of the applications showcased illustrate the strength and rigor
that we will will need?
#5: The biggest bang for our implementation buck
will come from buying/leasing software that's tested / already in
production, because good testing – for security and reliability – is defined in the requirements and
not cheap to build froom scratch. Doing so with agile methods is intriguing, but very demanding of systematic approach, analytic thought, and coding skill.
In response to William's invitation of course I'd like to
continue working on the plan; and then on the implementation. I can
probably do 15 hours, more or less, a week.
Richard Kerver (arkmundi) said: Process recomendations:
1. CGF should own its banking software (this is mission critical)
2. A web application development framework should be adopted rather than be developed, maximizing code reuse from the open source community
3. The framework should be based on the LAMP stack (Linux, Apache, MySQL, PHP/Perl/Ruby)
4. First steps would be to form a core IT team
5. The core IT team should first research, agree and write-up recommendations for an application development framework
6. The IT team should consider the Kuali RICE framework, among other qualifying frameworks (Ruby-on-Rails)
7. That recommendation should be made and formally adopted by the CGF management and advisory board, and should be included in the general business plan
8. Ultimately the project should become community source. The "community" are the CG banks, which own the software, set direction and maintain systems and staffing
Richard, this is great. Thanks for getting this ball rolling again. Backing up half a step, what we need are three things:
1. An IT Plan for running the bank (what software and hardware will we use, when the time comes — what are its components and features). Complete enough to guide purchases and/or development start to finish.
2. A much simpler summary/outline of that IT plan for two purposes: (a) to start with and flesh out and (b) to include in our formal business plan to present to the regulators (and to the public), to get a charter.
NOTE: Our 2009 3-person IT team (especially Kurt King) has already
CGF should own its banking software (this is mission critical)
A web application development framework should be adopted rather than be developed, maximizing code reuse from the open source community
The framework should be based on the LAMP stack (Linux, Apache, MySQL, PHP/Perl/Ruby)
First steps would be to form a core IT team
The core IT team should first research, agree and write-up recommendations for an application development framework
The IT team should consider the Kuali RICE framework, among other qualifying frameworks (Ruby-on-Rails)
That recommendation should be made and formally adopted by the CGF management and advisory board, and should be included in the general business plan
Ultimately the project should become community source. The "community"
are the CG banks, which own the software, set direction and maintain
systems and staffing
Team members should be adequately compensated with shares in the CGF corporation. CGF should attract essential expertise with a fair and equitable compensation package, recognizing the value of its people and the contributions they will make
The operational paradigm for team members should be modeled on worker cooperatives and ESOP's (employee share ownership)
Revenue for IT development should be generated by selling its banking software solution as services to non-participating banks (like credit unions); the prospect of revenue generation and a share in the revenue steam should be used as an incentive for early involvement
Initially, The Bank will use off-the-shelf software and out-sourced data-processing services as much as possible, mostly from Connecticut Online Computer Center (COCC). The simple customized software required for in-process transaction reporting (see Section II(B)(3)) will be supplied at no cost, by the Cooperative Sponsor. Ultimately, though, the Bank will use a customized combination of hardware and open source software, developed by the Cooperative Sponsor, to enable subsequent common good banksTM to get started more easily:
• OpenBSD (for server, phone interface and customer terminals)
• Customized customer-centric core banking software, based on
o GnuCash accounting software (using the XML specification of the
o SugarCRM customer relations management software, and
o PostgreSQL
• Further customizations for customer account access through the internet,
developed using Ruby on Rails
• Bayonne telephony software
• Benedict Group’s Loans! loan servicing system, or equivalent
• jPOS for electronic fund transfers
• OpenOffice (for employee workstations)
GnuCash will be configured to keep a complete audit trail and to require balanced credits and debits, closed periods and reversing entries (following Generally-Accepted Accounting Practices). Scanned deposit checks and EFT demand requests will be converted automatically to transaction requests, interfacing with jPOS software. In addition to standard accounting reports, specialized reports for management, for the OTS and FDIC regulators and for auditors will be created from the PostgreSQL database, using one of the many open source reporting systems.
All programming and customization will follow the principles of Extreme Programming: object orientation, simplicity, elegance, ongoing rigorous automated unit testing and acceptance testing, end-user participation, refactoring, collective code ownership, release planning and iterative development.
_________
The Kuali recommendation is a recommendation to change the business plan, specifically:
GnuCash: change to the Kuali Financial System, as outlined in this post; KFS will have everything in it, obviating the need for SugarCRM
PostgreSQL; good recommendation; the LAMP methodology involves an open source database, which would best be met by either MySQL or PostgreSQL; Kuali institutions most often opt for Oracle as their database; overtime, based on the number of database transactions involved, Oracle might be substituted; because of the modularity involved, one database can be easily substituted for another, and using standard database migration techniques, the data itself can be moved
Ruby-on-Rails: change to the Kuali Rice framework; Ruby-on-Rails is another Web Application Framework, wothy of consideration (see the Comparison), but unnecessary should the recommendation for Kuali be adopted
print page
Login 
Register 
Search 
Home
Add a New Topic
Reply to Post
Quote and Reply 
Print this Post 
I have sent William my resume.
Topic RSS 
