• The transition of the system from one provider to another, as reported in the October, 2007 Quarterly Report, is complete. The new vendor, Jacobson Consulting Applications (JCA - http://www.jcainc.com), is fully staffed and engaged.

• The Atlas core system, a hosted data warehouse, is fully operational and has been stable for six months. Any system needing to interface to FIMS or FoundationPower (or for that matter with any other) can easily be connected through a large set of secure web services.

• The local Atlas FIMS adapter is all but completely installed at Kalamazoo, and work has started to install it at Toledo. It has read/write access to profiles, gifts, grants and fund data. It also provides extensive logging and control what gets imported.

• An adaptor for Kintera Sphere (including grants, P!N and CRM) has been developed and tested. This adapter has not yet been configured so that Kalamazoo or Toledo can exchange data.

• Under contract with the TSC, Jacobson is porting the adapter to FoundationPower. On their own initiative, they are building adapters to other systems (e.g. CRM).

• JCA has proven a capable and flexible partner in Atlas development and implementation.

Just Why Again Are We Doing This?
For the past five years, the community foundation field has engaged in a bold experiment: to band together to address the inadequacies of the systems supporting their work.

Perhaps the center piece of the Technology Initiative was the goal of efficient data integration. No matter what new applications were developed, if they did not integrate to the legacy systems (FIMS and FoundationPower), they were not as useful as they might be for community foundations.

Over time, the number of "outside" solutions that could address specific functionality grew. Efforts were made, with varying degrees of success, to provide direct integration, called point to point, between these systems and core legacy systems.

However, even if the interfaces did keep pace, the solutions will become unmanageable. Each application has to be aware of each other one, and each will need to be modified each time any other is updated with a new version.

The Atlas Data Bridge is the Technology Initiative's solution for this technical challenge. The proliferation of point to point connections is instead replaced by a hub and spoke model. Each system has a single connector to the hub, and can ignore the state of another system.

The sole purpose of the Atlas Data Bridge is to enable the adoption of specialized tools to advance the capacity and efficiency of a foundation. It will gather these specialized tools into a meta system, embracing over time the depth and dynamics of philanthropy.

• Point #2: Despite its priority and considerable funding over the five years, integration projects have been delayed.

• Point #3: As of May, 2007, the Atlas project had fully demonstrated and tested the ability of a third party program to directly write to FIMS. Thanks to thoughtful leadership at MicroEdge, the speculations of legal issues were put to rest.

• Point #4: As of June, 2007, the technology used for the Atlas Data Bridge was found to be sound, and that indeed it exceeded expectations.

• Point #5: the past 8 months has witnessed a flurry of vendor projects (many now coming online) to provide point to point integration.

An offering directly from a vendor is not without its merits. They will often have a low short term costs, and offer the promise of support from a trusted business partner. They demonstrate that vendors are capable of responding to client needs.

Why choose the Atlas Data Bridge?

Even if vendors were to provide all of the connectivity desired by foundations, the basic approach will lead to enormous complexity.

The Atlas system is designed from the ground up to meet the needs of the field. Moreover, it is designed to evolve with those needs and expand to handle an ever growing body of information concerning the foundation’s business and relationships. It represents the fruits of a system with a price tag of over $1 million.

As new development teams have come on board to work on Atlas, there has been a consistent appreciation expressed for the depth of information held and technical sophistication of the architecture. This from experienced technical analysts and programmers.

So what? What does this technical achievement mean to an individual foundation?

• Case: The Kalamazoo Community Foundation is an early Atlas adopter. Its extended information ecology includes uses FIMS, DonorCentral (a donor portal), Community Impact System (for grants), eGrants (scholarship application) and Kintera P!N (prospect research).

  • With a Point to Point architecture, this would represent four separate interfaces to manage, four separate security configurations, and four separate technologies. Under this system the "child" applications will only be able to share data held in common with FIMS.

  • With the Atlas Hub & Spoke architecture: all systems use the same secure interface, and only one actual interface to FIMS is managed. All systems are able to interact as peers, contribute special data to the core warehouse and share it back with each independent software application.

  • The addition of a new "child" application (e.g. SalesForce) would add another layer of interface to manage in point to point, but would have no affect on the local Atlas adapter feeding data in and out of FIMS.

    • A proof of concept interaction between Atlas and SalesForce was developed in one week elapsed time (20 hrs coding), and this by a brand new programmer (no familiarity with the Atlas data bridge or SalesForce).

  • Support: Atlas is supported by the firm Jacobson Consulting Applications (http://www.jcainc.com) that is in the nonprofit integration business Its focus is solely on the interaction between systems.

How does Atlas position a foundation for the Future?
What is the future of business information technology? A hallmark of success in today’s business world is the open exchange of data across organizational boundaries. Businesses that share information with partners and customers are able to quickly learn and respond to changing needs.

This open exchange of information has been described as an Information and Communications Technology (ICT) Ecosystem. Open standards bind it together and open ICT ecosystems drive interoperability. These businesses have figured out what information is privileged and how to protect it while at the same time taking advantage of Web 2.0 advances.

The community foundation field has been struggling with the legacy of a "closed" information ecology. The vast majority of information that passes into or out of foundations has to be keyed-in or printed in hardcopy.

Openness is a nice idea, but what does it mean?

The Berkman Center for Internet & Society, Harvard University, studied the movement towards open information ecologies and developed a benchmarking tool. The content that follows presents two profiles from that study, one that resembles life in a point to point world; the other one designed using the same principles as the Atlas Data Bridge.

• The conditions created by the Atlas Data Bridge will foster the definition and documentation of common goals, standards, and practices, enabling cost/benefit analysis and encourage open communications to share frameworks and components.

• Compare this vision with point to point solutions, which inhibit communication, documentation and shared practices. The study found that this culture ignores the outputs of collaborative communities.
  

Comparative Systems Analysis
From "The Openness Maturity Model", The Roadmap for Open ICT Systems, The Berkman Center for Internet & Society, Harvard University, September 9, 2005. http://cyber.law.harvard.edu/epolicy/resources. This model applies the Capability Maturity Model (CMM) to systems interchange, and indicates that vendor based point to point solutions would be rated at a level 1 (0-5), where as the Atlas Data Bridge is at a level 3, (meaning it still has room for improvement).

	Vendor Based/ Point to Point	Atlas Data Bridge/ Data Warehouse
1. Interoperability enabled	Any interoperability is unplanned, though need may be understood.	Open ICT vision, goals, principles, components and baseline are defined and documented. Agencies are actively improving interoperability.
2. Use of open technologies	Use of open standards and open source is ad hoc, uncoordinated and often unsanctioned.	Standards profiles/ frameworks and use of open components are defined, accepted and cost-benefit evaluated.
3. Architecture framework	Documentation of business processes and ICT standards is informal and inconsistent.	Service-oriented business, information, architecture and technical frameworks are being defined by open standards.
4. Architecture development models	Use of modular components and service-oriented processes is minimal. · Any development of open standards/open source is unofficial.	Participation in development of open standards and technologies increasing, based on established guidelines, processes and documentation.
5. Communication & compliance	Use of open technologies is not communicated among agencies.	Well established channels of communications for sharing frameworks, policies and best practices for open standards and components.
6. Business process led or linked	Linkages between business needs/processes and ICT are rare.	Explicit linkage to and documentation of business strategies, needs and processes.
7. Linkages among operating units/ agencies	Little sharing of best practices.	Some linkages between business processes and systems among agencies.
8. Active management	Little active management of ICT ecosystem, though committees may be forming and processes planned.	Management is actively defining and developing open standards and frameworks.
9. Acquisition strategy/ ICT investment	At best individual agency may occasionally do procurements that reference open technologies. Most acquisitions are done in isolation with few examples of open and closed technologies competing.	Use of open standards in procurement practices of agencies, but no central rules or governance of acquisition strategies.
10. Collaborative communities	Any contact with or use of outputs from collaborative communities is unofficial and irregular.	Some official encouragement of collaborative processes for defining and developing open components.