Definitions

Owned by Former user (Deleted)
Last updated: Jul 18, 2005 by Former user (Deleted)Version comment
4 min read

Mark Norton

For starters, Google offers a few definitions of Enterprise Software:

  • Software that solves an Enterprise Problem (rather than a departmental one) and that is written with an Enterprise Software Architecture.
    see www.officevision.com/pub/p5ee/definitions.html
  • a software suite with common business applications, tools for modeling how the entire organization works, and development tools for building applications unique to the organization.
    see www.321site.com/greg/courses/mis1/glossary.htm

In our case, the "Enterprise" is a university – in all of its complexity. The university can be comprised of one or more campuses, one or more colleges, one or more departments, etc. Sometimes a single support organization (like IT) provides services to the whole university, but fiefdoms are also common.

However it is managed, there are groups within a university that maintain and control access to data collections. These collections might include:

  • Student information
  • Course information
  • Financial data
  • Library services including repositories of digital assets
  • Security including authentication and authorization
  • HR data for employees

Enterprise Integration refers to the challenge of connecting a set of web applications (Sakai, in our case) to the data collections managed and controlled by other groups within the university (enterprise). Integration must address the following issues (at least):

  • Timely access to data
  • Changes and updates to data
  • Consistency checking
  • Security and access rights
  • Backups, Error Recovery, etc.
  • Auditing and system monitoring

Enterprise Performance refers to the challenge of delivering a highly reliable system that meets the needs and expectations of the university (enterprise). Performance must address the following issues:

  • Uptime - 24/7, 99.99% or other criteria set by university
  • Provisioning - server configuration, failover, redundancy, etc.
  • Efficiency - how well system performs under a given load

Casey Dunn

What Enterprise means to my CIO (or has in the past, Stanford is another story. I don't know if we
have a CIO this week):

  • Transactions
    • rollback of
    • replay of
    • logging of
  • Auditable
  • Recoverable - nothing is ever "just gone"
    • including Transactions

Andrew Petro

"Enterprise Sakai" is the "opposing" consideration to "Product Sakai". From the Enterprise perspective, Sakai is not merely a product to bring online, but rather is a framework, an API, a technology that is part of a larger timetable and effort to deliver learning and collaboration services in support of the mission of the educational enterprise.

It's great that out of the box Sakai provides mechanisms to manually create courses, provides local within-Sakai authN, AuthZ, Groups, and Plumbing.

But of course we want to be able to replace every one of these pieces with the Enterprise-level versions, the ones we're using elsewhere, with which we have gathered staff expertise, and in which we have an infrastructure investment.

Sakai should be an excellent standalone product, should be quality and reliable and scalable and so forth. I don't see these as Enterprise considerations.

Sakai should benefit from and play nicely with the other services, infrastructure we educational IT people provide. This is SEPP-ENT's concern.

This means that Sakai provides monitoring hooks, industry standard logging, and appropriate recovery and error messages, so that the personel who already provide support, system administration, operations support for existing Java web application can apply their best practices to Sakai. It means that Sakai should be only as eccentric and esoteric as it really has to be.

From the "Sakai as product" perspective, it is in some sense okay for Sakai to do whatever it needs to do inside its black box to be a good product.

From the "Sakai in Enterprise" perspective, Sakai needs to feel as much like "just another web application" as possible.

On the subject of clean branding, navigation, and doing what needs to be done to provide a 24x7 service offering: There are aspects of these which I see as "enterprise" considerations – Sakai should be brand-able so that it can be deployed as part of a larger suite of tools and services. Fitting into the enterprise and playing well with existing infrastructure. Branding, navigation, and stability are also "Sakai as product" concerns as well, and I'd like to see the SEPP-Enterprise group get to dodge some of that being our direct concern.

We talked (on a conference call) about taking some things as given. I'd like for SEPP-ENT to be able to take it as a given that the Sakai product as standalone will have excellent navigation and stability for 24/7 service offering. The product should be quality, and everyone needs that, even if you're just going to bring it up out of the box and never integrate it with anything. Given that, Enterprise considerations are being able to customize that navigation to fit with existing enterprise context, monitorability of the Sakai instance, ability to produce / share Operations procedures for responding to a sick Sakai instance, etc.

Enterprise means a Sakai amenable to being part of a larger context. We don't bring online Sakai just for the sake of bringing online Sakai. We bring Sakai online as a resource in support of a larger endevour including other technologies and non-technological considerations.

The above seems to be mostly about "Enterprise". I'd like to throw a few words out about "Integration". Integration means not only that Sakai can consume existing goodness, existing services, in the forms of AuthN infrastructure, directory services, enterprise filestores, enterprise RDBMS, etc. Integration also goes the other direction: it means federatability of Sakai content and information.

It means that we provide relevant links to, IFrames of, WSRP consumers pointed at, Sakai in our "enterprise" portals. It means that we can integrate Sakai with a library course reserves system such that when an end user visits the library course reserve site she can see the course reserve information specific to the courses she's taking. It means that Sakai tools can kick out interesting RSS feeds such that an end user might choose to receive announcements for a site via email or might choose to visit Sakai to see them, but mght just as well choose to aggregate Sakai content into her Thunderbird on her desktop, only visiting the actual Sakai site when the feeds inform her there's something there worth looking at..