Managing Information Technology

Case Study III-4 • The Kuali Financial System: An Open-Source Project 461

includes high-level standards on methodology and system

architecture and detailed standards concerning the tools

and technologies that may be employed.

The following excerpt describes the standard

methodology:

In general, the Kuali development methodology is a

lightweight, iterative approach to development that

focuses on individual components that can be quickly

developed and integrated into a larger application

taking into account in all cases the knowledge and in-

vestment that is being carried forward from the origi-

nal IU FIS system. Frequent communication and

interaction with users is requiredin order for this

methodology to succeed. By simplifying the develop-

ment process and emphasizing frequent feedback, the

software product has a much greater likelihood of

meeting the user’s needs.

Another fundamental rule of the Kuali method-

ology is to KEEP IT SIMPLE. Developers should

resist the temptation to add unnecessary complexity.

The following describes the standard architecture:

The contemporary architecture of applications is a

set of distributed, loosely-coupled components and

services that provide distinct business services. A

Service-Oriented Architecture (SOA) approach to

Kuali development is recommended. This architec-

ture assumes service delivery via an enterprise portal

framework and the presence of key infrastructure

services like a single sign-on solution, an enterprise

directory, and an enterprise workflow engine. In

addition, a standard Application Program Interface

(API) for common services like authentication and

authorization should be agreed on.

Components should be designed to build the

application into three layers: Presentation, Business,

and Persistence layers. Components should be

container-agnostic and use standard J2EE proven

APIs such as Servlet and JSP. All system-to-system

interoperability that cannot be done within the

container should be done using Web services tech-

nology that uses Apache Axis.

The Presentation layer focuses on the presen-

tation of the data to the user in the context of the user

interface, e.g., the Web browser or a rich client. The

Presentation layer that we are building for the out-

of-the-box version of Kuali is intended to be used

through a Web browser as a standard HTML-based

Web application.

The Business layer provides the enterprise

logic. It includes the components that capture the

System” because, like the human nervous system, it ties to-
gether and coordinates everything.
As the project got under way, the board served as the
court of last resort when disputes arose. Any partner could
escalate a dispute to the board, but fortunately that was done
infrequently because the Technical and Functional Councils
were very effective in working things out at their level.
Increasingly as the development process settled down, the
board turned its attention to developing a broader long-term
mission for Kuali and modifying the organizational
arrangements to accommodate that expanded mission.
The board provided outstanding leadership to the
project. The members of the board were dedicated to the
vision of providing open-source administrative systems to
the educational community. They consistently put the best
interests of the overall project ahead of the interests of their
own institutions, so the Kuali Financials project prospered.

The Technical Council

The Kuali Technical Council (KTC), chaired by Brian
McGough of IU, was composed of one representative from
each of the partner institutions. The role of the Technical
Council was to provide and enforce technical standards for
the Kuali Financial Systems project. Because the systems
development was spread out over the IT organizations of
seven geographically dispersed institutions, each with its
own development culture and practices, without uniform
standards the resulting system would be difficult to support
and maintain. Without standards, two team members from
different institutions would find it very difficult to work
together on a module.
Eighty percent of the total lifetime cost of software
goes to maintenance. The original author of the code often
does not perform the maintenance. This is particularly true
with open-source projects. Applying standard development
practices across the Kuali project results in substantial main-
tenance savings for everyone. Good standards promote better
quality applications, code reuse, and enhanced portability.
If a developer felt it necessary to deviate from a stan-
dard, the first step was to communicate with the Kuali
Technical Council. The Technical Council then applied its
collective knowledge and experience to arrive at a recom-
mended approach. Often the Technical Council found a
way to solve the problem and still adhere to the standards.
Otherwise it might decide that an exemption to a particular
standard was justified.
The members of the Technical Council were experi-
enced architects, designers, and developers who brought a
wealth of experience and wisdom to the table. They
worked together effectively to produce a document titled
“The Kuali Architecture and Development Standards” that