ifc 2006 - famis adaptive architecture · famis adaptive architecture: an introduction...

FAMIS Adaptive Architecture – IFC 2006

Author: Michael LaFleur

Created: December 15, 2005

Updated: August 10, 2009

Version: 1.4

FAMIS is a trademark of FAMIS Software, Inc. Various product and service names may be trademarks of FAMIS Software, Inc.

All other products mentioned may be trademarks of their respective owners. Copyright © FAMIS Software, Inc. All rights reserved.

Table of Contents

FAMIS Adaptive Architecture: An Introduction .................................... 5

Contingencies .......................................................................... 5

“On a Uniform System of Screw Threads” ......................................... 6

Back to the CDs ........................................................................ 8

The Shop-Culture of Software ...................................................... 10

FAMIS Adaptive Architecture.........................................................15

Functional Benefits of FAA .......................................................... 19

Business Benefits ..................................................................... 19

FAMIS Adaptive Architecture........................................................ 20

FAMIS Software, Inc. 5

FAMIS Adaptive Architecture: An

Introduction

Contingencies

As some of my readers may know, two years ago, at our annual user conference, I

was the unwitting victim of a strange set of incidences that traumatized me to

such an extent that, still to this day, I often wake in a cold sweat, have tremors in

my hands, and occasionally blackout when the incidents are dredged up from

memory. Okay, so it wasn’t that bad, but in all honesty, I have never looked

preparation a presentation in the same light-hearted, carefree way I had in my

youth.

Not to dwell at too great a length on that dreaded day in 2004, I will only offer

the briefest of litanies to spell out what happened, leaving out the details of my

impending psychological decline:

• First, I could not fit my USB “thumb drive” into the presentation

computer, meaning I could not load my PowerPoint slides. This caused

the first of the embarrassing delays.

• Second, once I did get my slides on the computer, the mouse and key

board quit working, necessitating another delay for our crack support

staff to rush in to fix it.

• Third, after having the input devices repaired, I was able to begin my

presentation, and when it came to the point of accessing the Internet,

there was no joy as the network failed.

• Fourth, with the network repaired, I dutifully returned to my

presentation, only to find the server I was using to demonstrate on

would crash when I accessed the application.

• Graciously, other presenters stepped up and filled in with actual

working presentations, schedules were shuffled, and I was scheduled to

retry the presentation in a later timeslot.

• Fifth, with the server rebooted, network checked, input devices at the

ready, I tried the application with great trepidation; the server promptly

died as it had before.

With each of my successive hurdles, my mouth grew drier until I could barely

speak, the audience inexplicably swelled to ten times its original size, and my

jokes—a lame attempted to fill the dead air while we attempted to get back into

the game—grew progressively worse. Having weathered such a miserable and

FAMIS Adaptive Architecture: An Introduction

6 FAMIS Software, Inc.

public failure garnered me valuable experience—the master of all teachers. My

experience in Hollywood that year has taught me to always have a contingency in

place; that is, I have learned to be more adaptable to what the fates may throw

my way when presenting.

In 2005, happily, my presentation went off without a hitch; no hardware

problems manifested themselves; I had no need for the network; and I was able

to load my presentation on the machine a day in advance. Even though, I made it

through unscathed, I did have contingencies in place. For example, I made sure I

was not reliant on the network when preparing. I had multiple copies of my

PowerPoint slides, on CD and “thumb drive.” I even brought my cherished, dog-

eared copy of “Beowulf.” (I even plied the audience with a brief selection from

that venerable poem.) The relative smoothness of this presentation has eased my

psyche somewhat, but I have indeed learned my lesson.

In preparing for my presentation at the 2006 conference, one of the first

concerns I addressed was my contingency plans. Not relying on the network and

making multiple copies of my slides on a variety of media—those were the easy

part, the proverbial “no brainer.” The real poser was the filler. After all, perhaps

there are those who are not inclined to appreciate esoteric, erudite, and

impenetrable poetry; and besides, I already read to the audience making that

very 2005. What I needed was something a bit more . . . universal.

“What’s more universal than music?” I decided. Not only is music itself universal,

I would even be able to play music suitable to the tastes of the members of the

audience, making the experience all the more enjoyable. All I would have to do is

have a CD player, or multiple even to address the possibility of multiple musical

tastes, and ask our gracious attendees to share their personal CDs. I convinced

myself that this was absolutely brilliant.

Then a thought occurred to me, “What if someone’s CD doesn’t play in the CD

player?” How do I know a CD from Arkansas plays in a CD player from

California? And what about a Canadian CD? Or what about a CD from the UK?

Surely, they would all play in the CD player wouldn’t they?

“On a Uniform System of Screw Threads”

The reason that we can reliably assume that any particular CD player is capable of

playing any particular CD is directly attributable to one William Sellers.

Technological innovation in the second part of the 19th century took place in the

machine shops of the American Industrial Revolution. By building lathes,

presses, and drills to help other manufacturers create rifles, sewing machines,



and mills, these machine shops provided the infrastructure for business—much

like computer network and middleware vendors do today.

At the time of unprecedented growth in mechanization in industry, there was a

lack of contingency when the machines broke down; all replacement parts for

equipment of this time had to come from the original builder, i.e. the machine

shop—including the nuts and bolts. All fasteners—screws, nuts, bolts were

custom-made by machinists. A maintenance technician couldn’t simply pop on

down to Granger and pick up replacement bolts.

On April 21, 1864, William Sellers delivered a speech titled “On a Uniform

System of Screw Threads.”—a speech that would launch the first successful

standardization drive in history. While Sellers did propose a specific standard for

screw threads that evening in his address to the Franklin Institute, the

professional society of machinists, his call to arms was more in support of

standardization itself, rather than a call to his standard.

While viewed rational by most, there were machinists who viewed the proposal as

a threat to their way of life. Although they made their living building machines

that were designed to pump out mass-produced goods, the machinists did not use

mass-production techniques themselves to create nuts, bolts, or screws. Some

machinists saw the screw standards as the first step on the slippery slope of

commoditization. Having tailor-made screws on the equipment they

manufactured ensured customer lock-in.

Even though Sellers was a craftsman himself, he was also a pragmatist. He

foresaw the inevitability of interchangeable parts and mass-production. His

proposed standard produced a screw that was easier, cheaper, and faster to

produce than any other to fit with the emerging economy that valued speed,

volume and cost. His pragmatism also led him to recognize that having a superior

standard would not be enough to ensure success; he recognized that he needed

consensus.

Sellers diligently worked behind the scenes, before he made his presentation to

the Franklin Institute, and convinced four of the East Coast’s largest machine

shops to adopt his standard, as well as implementing it in his own shop, whose

customers included large customers such as locomotive manufacturers and

railroads. Upon making his presentation, he lobbied the Institute itself, which

later set up a special committee to investigate the issue, and on December 15,

1864, the special committee of the Franklin Institute endorsed what was to

become known as either Sellers or Franklin Institute thread standard.



The Franklin Institute endorsement and the early adoption by large machine

shops set the stage for further implementation of the new standards. In the

spring of 1868, the U.S. Navy commissioned an investigation into the need for a

standard. The Navy began its investigation by examining the technical merits of

Sellers screw threads and found them to be technically superior to others being

proposed, but technological superiority was not enough. (Remember this. I’ll

come back to this later.) The Navy wanted to support the standard that was most

likely to be adopted. To determine this, they surveyed sewing machine

manufacturers, shipyards, locomotive makers asking two simple questions. “Are

your screws standardized? If so, what standard do you use?”

The Navy determined that the Sellers standard was the most popular, and the

Navy took this popularity as an indicator of quality. The marketplace had spoken.

The Navy wholeheartedly endorsed the Sellers standard, making it the Navy’s

recommended standard. By the end of the 19th century, the Sellers Standard was

effectively universal in America.

And this is how I knew any audio CD would play in any CD player. CDs are

manufactured using industry standards, and Sellers’ speech is widely recognized

as the first call for the formal establishment of industry standards.

Back to the CDs

The formal standard for the manufacture of audio CDs is called “The Red Book”

standard. Legend has it that the original specification document for compact disc

digital audio was held in a binder with red covers, and specifications for other CD

formats were held in other colored binders. For example, the specification for

CD-ROMs is referred to as “The Yellow Book.”

The first edition of The Red Book described the CD's physical specifications, such

as the tracks, sector and block layout, coding, and sampling. Released by Sony

and Philips in 1980, it defined the compact disc as a content medium for audio

data digitized at 44,100 samples per second (44.1 KHz) and in a range of 65,536

possible values (16 bits). For all intents and purposes, any CD available will

comply with these standards.

Notice that the original standard was initially released by competitors. Sony and

Phillips both manufacture CDs and CD players, but a Sony CD will play in a

Phillips player and vice versa. Currently the specification of the standard is

maintained by the Digital Audio Disc Committee of the International

Electrotechnical Commission and is designated as IEC 908. Today countless

manufacturers of audio CDs and CD players exist, and all are compliant with IEC



908. (Well the ones that want to ensure their customers will be able to use their

products in the long term are anyway.)

Thankfully, I don’t have to worry about the exact specifications, do I? I can

reasonably assume that I can take any CD and play it in any CD player.

But what about Betamax?

In 1974, Sony was preparing to launch the first home videocassette recorder. The

videocassette used a specification developed by Sony, named Betamax. In

preparation for initial sales, Sony invited rival electronics manufacturers to

preview the technology but spurned offers of advice or joint-development,

preferring at the time to keep the revolutionary technology and its specifications

to itself.

Meanwhile, JVC quietly developed a competing videocassette recorder and a

competing specification dubbed Video Home System (or VHS). Unlike Sony, JVC

chose to license the VHS specification to other manufactures, while Sony kept

Betamax to itself, touting Betamax’s technological superiority and maintaining its

higher price.

Many maintain that Betamax was technologically superior, but as VHS became

more widely adopted, movie studios began to release a greater number of films in

VHS format and fewer in Betamax. The wider the adoption of VHS, the more

pronounced the demise of Betamax became. (Here’s where I was pointing to from

the Navy’s investigation of the Sellers standard.) Technological superiority is not

sufficient to guarantee success or even survival.

By Sony’s own admission, Betamax failed because Sony did not attempt to build

consensus for Betamax as a standard. While, it did in the end license Betamax to

some other manufacturers—including Toshiba, Pioneer, Aiwa, etc.—Betamax was

overwhelmed by JVC’s decision to share its proprietary technology, which

eventually created an industry standard and ultimately to Betamax’s demise.

Sony was unsuccessful with Betamax where Sellers was successful with his screw

thread. While both Betamax and Sellers thread were technologically superior,

Sellers worked to build consensus, adoption by competitors, and

recommendation by standards bodies; Sony chose not to.

What difference do standards make?

Let us consider how we got to this place. In preparation for a large presentation, I

determined that I needed a contingency in place—a contingency that would



permit me to adapt to unforeseen, changing conditions; a contingency that would

allow me to be agile.

I chose to have multiple sources of content—a variety of CDs from a variety of

sources. And this content would be available and accessible to multiple content

consumers—a few different CD players. Should something in my presentation

begin to fail, I would be able to adapt by playing CDs. If a particular CD failed, I

could be agile and switch CDs or players.

The means by which I was able to maximize my agility and adaptability was by

choosing a standards-based approach, an approach where the components—my

service provider, the CD manufacturer; the transport, the CD itself; and the

service consumer, the CD player—all adhered to a standard; in this case IEC 908.

The Shop-Culture of Software

Even the most cursory survey would find in many of the software vendors of the

21st Century an amazing resemblance to the machine shops of the 19th Century. In

essence, the shop-culture of the 19th Century is alive today in many software

development houses. Just as in Sellers’ day with equipment built by machine

shops using proprietary components—including the nuts and bolts—software is

often designed and developed with no eye toward external interoperability,

extensibility, or maintainability. As in the case of the sewing machine

manufacturer who had to bring in the original builder of their equipment for even

rudimentary maintenance—let alone adaptation—many enterprise applications

require the original vendor, or some sort of tool provided by them, in order to

make even the most simple change to something as critical and yet slight as a

business process—and perish the thought of attempting to create or adapt a

process that involved a third-party.

To be fair, until recent technological advancements it was nearly impossible to

design a software application to be adaptable and agile. Indeed, there have been

myriad innovations that vendors have implemented that allow users to do things

like change the user interface, develop internal workflows, or create custom data

entities. Unfortunately, many of these have used the Betamax model for

implementation; in short they are not standards-based. It could be certainly be

hazarded that these models, while nice at first blush, ultimately still lead to

vendor tie-in. The only way to ensure maximum agility is to provide the needed

functionality while adhering to standards.

In order shed the limitations imposed by the shop-culture, software vendors with

foresight have recognized the need to create an operating environment that



allows for customer agility, similar to the agility offered by CDs, for example. If

we consider the three criteria that sealed the success of the compact disc:

• Consensus

• Adoption by competitors

• Recommendation by standards bodies

One technology architecture begins to resonate clearly—the Services Oriented

Architecture.

Services Oriented Architecture

In software terms, a Services Oriented Architecture, or SOA, is an architectural

concept where software resources are made available as independent services,

which are accessed in a standardized way. A service is a unit of work done by a

service provider to achieve desired end results for a service consumer. Both

provider and consumer are roles played by software agents on behalf of their

owners. SOA has as its primary goal to achieve loose coupling among interacting

software agents.

Perhaps this strict definition of SOA is a bit dense and abstract. Since we have

already been talking about CDs in the past few pages, perhaps we can use them to

illustrate an SOA.

Notice that an SOA is comprised of producer and consumer agents. From our

earlier example our producer is the CD manufacturer. Our consumer is our CD

player. As I have demonstrated, I am not tightly bound between CD producers

and CD players; in essence, CDs and CD players are loosely coupled. I can take

any CD and play it in any CD player because both CDs and players are standards

compliant.

The concept of loose coupling in SOA departs significantly from traditional

software models, which often binds data and its processing together. If CDs were

manufactured in the same way traditional software is written every CD would

come with its own player, and it would not be possible to separate the two

without the vendor’s involvement. This is even worse than the Betamax model,

CD Manufacturer CD Player



isn’t it? While it sounds perplexing and nonsensical, it's still the way many

software systems are still being architected.

Strictly speaking, an architecture must comply to four criteria before it can be

deemed to be an SOA:

• First, the messages between provider and consumer must be descriptive,

rather than instructive.

• Second, messages must be in a format, structure, and vocabulary that

are understood by all parties.

• Third, messages must be extensible, or consumers and providers will be

locked into one particular version of a service.

• Fourth, an SOA must have a mechanism that enables a consumer to

discover a service provider under the context of a service sought by the

consumer.

Services Oriented Architectures in and of themselves are not new concepts. Prior

manifestations of SOAs included Distributed Component Object Model (DCOM)

and Common Object Request Broker Architecture (CORBA). While CORBA is

regarded as the first service-oriented architecture by many people, the promise of

loosely-coupled, highly-interoperable application services remained largely

unfulfilled until the introduction of the Web Service.

Web service

According to the World Wide Web Consortium (W3C), the governing body for the

World Wide Web standards, a Web Service is a software system designed to

support loosely-coupled, highly-interoperable machine-to-machine interaction

over a network. By definition, a Web Service must use an Internet protocol for

message exchange, and messages must be in XML. (Internet communication

protocols include HTTP, FTP, and SMTP. XML, or Extensible Markup Language,

is a markup language capable of describing many different kinds of data. Its

primary purpose is to facilitate the sharing of data across different systems,

particularly systems connected via the Internet.)

Two governing bodies oversee the Web service specification, Organization for the

Advancement of Structured Information Standards (OASIS) and the W3C are the

primary committees responsible for the architecture and standardization of Web

service. OASIS and W3C have determined that in order to be standards

compliant, Web service must make use of the Web service Protocol stack.



The Web service protocol stack is the collection of computer networking

protocols that are used to define, locate, implement, and make Web service

interact with each other. The Web service protocol stack is comprised of four

areas:

• Service Transport: It is responsible for transporting messages between

network applications and includes protocols such as HTTP, SMTP, and

FTP.

• XML Messaging: It is responsible for encoding messages in a common

XML format so that messages can be understood at either end of the

network connection. Currently, this area includes such protocols as

XML-RPC, SOAP and REST.

• Service Description: It is used for describing the public interface to a

specific web service. The WSDL protocol is typically used for this

purpose.

• Service Discovery: It centralizes services into a common registry such

that network Web service can publish their location and description,

and makes it easy to discover what services are available on the network.

At present, the UDDI protocol is normally used for service discovery.

By adhering to the Web service standards, services are able interoperate based on

a formal definition independent of the underlying platform and programming

language. The interface definition hides the vendor and language-specific

implementation, making an SOA implemented using Web services independent

of development technology (such as Java and .NET). The software components

become very reusable because the interface is defined in a standards-compliant

manner. So, a consumer written in a language like Java for example can consume

services written in .Net, and vice versa.

As noted, Web service specifications are governed by two standards bodies,

OASIS and W3C. As demonstrated with the example of the Franklin Institute’s

recommendation for the Sellers’ standard, while important, governance alone is

not enough to ensure the traction of a standard; consensus is also required. Web

services are currently supported by industry heavies such as: IBM, Microsoft,

Sun, Oracle, BEA Systems, SAP, FAMIS Software, Inc., et. al.

Just as the support by competitors, widespread adoption, and governance by a

standards body ensured the success of the CD, the groundwork for success and

longevity has already been laid for Web services, and by extension, for those

technology companies that comply with the standards.



A Preponderance of Acronyms

Many people, myself included, are acronym averse. Some people’s aversion goes

as far as to cause their eyes to glaze over, their breathing to slow down, and pulse

to drop significantly when a barrage of acronyms begins to fly—a state not unlike

catatonia. Perhaps this occurred to you, gentle reader, while reading the

introduction to Service Oriented Architecture and Web services. If that is the

case, fear not, I am about to describe a Web service in terms more . . . universal.

(You guessed it: using CDs.)

To reset the stage, in my contingency scenario, I had multiple CD players at the

front of the presentation room. Scattered throughout the audience I had people

who had CDs they were willing to have played. These gracious persons are our CD

producers, and the CD players are our CD consumers. For the purposes of

illustration, our CD producers would have some means of letting us know what it

was they provided; let’s say a catalog. Additionally, I would have some way of

identifying them in the room full of over 200 people; let’s say a placard. Further,

I would have a set of envelops to use for putting CD requests and responses in. If

I were ambitious, I would have some means, say a rope and rings attached to the

envelopes, that would allow me to move the CDs from the producer to the

consumer, without having to walk over.

So, to discover who had CDs available, I would ask the audience to raise their

placards. I would then request to see their catalog of available CDs. When I found

a CD I wished to play, I would send them an envelope with a request for the CD,

using my rope and ring system. They would send the requested CD back, also

using an envelope and the rope and ring. I could then play my CD.

Referring back to its protocol stack, Web services are made up of four

components: transport, message, description, and discovery. In my scenario, the

transport is the rope and ring, the message is the envelope with the request and

the CD, the description is the catalog of CDs available, and the discovery is the

placard. To reiterate, the producer is the CD holder, the consumer is the CD

player, and the data being exchanged is the CD itself. As demonstrated earlier,

since any CD can play in any CD player, this actually makes a pretty decent

physical metaphor for describing a Services Oriented Architecture implemented

using Web services.

FAMIS Adaptive Architecture



The only thing consistent in the business world is change. It has long been the

permanent challenge to organizations, to meet change at the speed of

expectation. Increasingly technology driven, the speed and unpredictability of

change have pushed many enterprises to the very limits of manageability. In

order to meet the challenges change presents, organizations have to develop

adaptive responses, attitudes, and techniques.

At FAMIS Software, we recognize that the rapid ability to meet the changes

wrought by today’s business environment is crucial, and software should not

stand in the way; rather, it should enable change. This is the reason we have

created the FAMIS Adaptive Architecture.

The FAMIS Adaptive Architecture is a Services Oriented Architecture founded on

loosely-coupled business services that are interoperable and technology-agnostic

allowing for unprecedented business adaptability. FAMIS’ services enable

standards-based, end-to-end business processes, which can be orchestrated via a

standards-based enterprise workflow technology, such as Business Process

Execution Language (BPEL).

Because it is based on SOA, the FAMIS Adaptive Architecture mitigates the risks

associated with non-standards-based technologies while maximizing adaptability

and agility. The FAMIS Adaptive Architecture does not impede change; it enables

it.

FAMIS’ Services

One way to conceptualize how FAMIS services will work in the FAMIS Adaptive

Architecture is to think of them as components. Under the FAMIS Adaptive

Architecture, functionality is provided as a set of components. This vast set of



FAMIS components can be drawn from to easily create a customer-specific

application. An example would be a self-service work approval component that

allows requestors to approve work that is billable. Some FAMIS customers will

include this component in their application while others will not.

This component structure is not limited to FAMIS either. Sometimes customers

will bundle non-FAMIS components into their FM application. For example, a

Banner purchase requisition component can be added to FAMIS, allowing the

creation of Banner purchase requisitions from within FAMIS. This is not a

traditional interface; it is actual Banner functionality within FAMIS.

Additionally, FAMIS Software is a member of the OSCRE (Open Standards

Consortium for Real Estate), which is the standards body responsible for defining

communication, collaboration, and standardization within the commercial real

estate industry. Among the standards in development are XML data interchange

standards for data entities such as work orders and purchase orders. As a

member and contributor to OSCRE, FAMIS utilizes these standards to enable

seamless data interchange with service providers, contractors, vendors, etc. using

standards compliant components.

The FAMIS Adaptive Architecture is comprised of five types of components, or

types of services. While the overall architecture itself is standards-compliant,

each of the types of services also complies with standards specific to the service

provided. These sets of services interoperate within FAMIS as well as with

external technologies allowing for extreme flexibility.

Composite Java Application Services

Composite Java Application (CJA) services provide rich, extensible Java clients

that are optimized for use over the Web. Since they are services, these FAMIS

CJA components allow for the leveraging of XML, Java, and other services, such

as BPEL.

CJA services provide the user interface for intensive, heads-down FAMIS users.

They are intended to be utilized by users whose day-to-day responsibilities

involve intensives and extensive use of FAMIS.

FAMIS CJAs implement these standards: JSR 176, JSR 154

Presentation Services

Business functionality within FAMIS can be accessed via its presentation

services. These services take the form of Web Services for Remote Portlets

(WSRP) compliant portlets.



FAMIS acts as a producer of portlets that any WSRP-compliant portal can

consume. This allows for the incorporation of FAMIS functionality into third-

party portal environments. This enables organizations to provide a consistent

user experience while providing FAMIS functionality in their environment.

FAMIS Presentation services implement theses standards: JSR 252, JSR 168

Query Services

FAMIS allows access to data via standards-based query services. For example,

users can extract XML data from FAMIS. XML data provides a flexible and

adaptable means to identify information. (Remember that the difference between

data and information is that data is raw and information is usable.) From one

source of XML-based information—the results of a FAMIS query—users can

format and distribute it via a multitude of different channels with minimal effort.

An XML query result can be opened with Excel, transformed into HTML, or

imported into a third-party system—all from one document.

XQuery is a standard that provides the ability to not only query relational data,

such as contained in a database, it also allows for the query of XML documents. It

also allows for the aggregation of queries between a relational database and an

XML source. This means users can create queries that simultaneously look at

data from FAMIS as well as third-party systems.

FAMIS Query services implement these standards: XQuery, XML 1.1, XSLT 2.0,

XPath 2.0 (All W3C Specifications)

Business Logic Services

FAMIS business logic services are object services, that is they are discrete, self-

contained, and perform a specific function. The function an object service

performs can be anything from a simple request to a complicated business

process.

FAMIS Object services allow FAMIS to interoperate with third-party

applications, regardless of the technology architecture of the applications, using

Web services as the standard.

(A simple example of a FAMIS business logic service would be a purchase order

service which can be used by third-party services to create purchase orders in

FAMIS.)



FAMIS Object services implement these standards: JSR 252, JSR 220, SOAP 1.2,

WSDL 2.0, et. al.

Workflow Services

FAMIS provides end-points, or workflow services, which can be referenced by

BPEL in order to create standards-based enterprise workflow. The workflows

themselves must be defined during implementation, but they will make use of

FAMIS Workflow services.

FAMIS Workflow services implement these standards: WSBPEL 2.0, SOAP 1.2,

WSDL 2.0, et. al.

External Technologies

Since the FAMIS Adaptive Architecture is inherently interoperable the following

represent a sample of how external technologies might make use of FAMIS

services.

WSRP-Compliant Portal

Since FAMIS is an SOA environment, any WSRP-compliant portal can be used to

provide users access to FAMIS functionality. This allows users to aggregate data

from multiple systems while providing a consistent and intuitive user interface.

Service Consumers & Third-Party Applications

In terms of adaptability, this is perhaps the most feature rich aspect of the FAMIS

Adaptive Architecture. Because of FAMIS’ provision of services, users can

consume FAMIS functionality in astoundingly broad ways. These ways can be

anything from an integration point, such as purchase orders, to creating an

entirely new user interface for FAMIS.

Enterprise Workflows & BAM

FAMIS services can be incorporated into enterprise workflows, meaning users

can create workflows that include FAMIS, third-party systems, and manual tasks.

Workflow is not constrained to just FAMIS.

Additionally, FAMIS services can be consumed by Business Activities Monitoring

systems to provide real-time business process analysis.

User Interface

Finally, FAMIS Presentation services, as well as FAMIS CJA services, can be

viewed via any standards-based browser.



Functional Benefits of FAA

Through its standard-based approach, the FAMIS Adaptive Architecture offers

significant functional benefits:

• Interoperability - no practical difference between services and

capabilities inside the enterprise and those that exist outside it. FAMIS

can be integrated seamlessly and transparently with third-party,

standards-based applications.

• Flexibility in Design - for users within the operational environment, the

main advantage is that they are now supplied with precisely the facilities

services that are most useful, not those that the facilities management

system will permit them to provide.

• Targeting Business Process - FAMIS can assume the role of broker and

orchestrator, allowing the organization to identify the best sources of

key components, combine these in the right configurations, and then

deliver them faster, cheaper and more reliably.

• Enhancing Design Change - when services change, the most important

technique involved is recombination of components into different

configurations.

FAA allows your organization to develop a 360-degree view of your facilities

organization, using industry-standard Web services technology to assure all

aspects of your operation work together for improved agility. This approach helps

you facilitate business process change, support new business models, and

dynamically integrate customers, partners, employees, and applications.

Business Benefits

While the change is often unexpected and disruptive, organizations that adapt

quickly gain a competitive advantage. The adaptation wrought by the drivers of

change can be summarized into three primary customer benefits: simplicity,

agility, and value—all of which can be gained from the FAMIS Adaptive

Architecture.

Simplicity

• Reduce complexity

• Implement change quicker and easier

• Ensure resources are working together

FAA brings simplicity by harnessing the power of the Services Oriented

Architecture, making integration and adaptation more efficient. By simplifying



and streamlining the technology environment, FAA enables a more successful

deployment of FM solutions and supports business changes—more responsively,

with less risk.

Agility

• Adapt in real-time to business needs

• Drive change, instead of have change drive

FAA increases business agility allowing organizations to be able to identify and

quickly respond to challenges and opportunities and to quickly adapt to changing

business models, processes, and customer demands.

Value

• Unlock the value of technology assets

• Free up resources for innovation

• Create competitive advantage

FAA improves overall value by increasing the quality of service. It enables an FM

organization to confidently establish and meet increasingly aggressive service-

level agreements, response times, and performance.


FAMIS Adaptive Architecture defines the blueprint for the next generation of

FAMIS products. By harnessing the power presented by a standards-based

Services Oriented Architecture using Web service and other supporting

technologies, FAMIS is creating the next generation facilities management

system—a system that delivers flexibility, interoperability, and scalability

resulting in a reduced long-term cost of ownership.

FAMIS Software, Inc.

4 Park Plaza Suite 1000

Irvine, CA 92614

[email protected]

(800) 774-7622 corporate

ifc 2006 - famis adaptive architecture · famis adaptive architecture: an introduction...

Documents