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,
FAMIS Adaptive Architecture: An Introduction
FAMIS Software, Inc. 7
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.
FAMIS Adaptive Architecture: An Introduction
8 FAMIS Software, Inc.
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
FAMIS Adaptive Architecture: An Introduction
FAMIS Software, Inc. 9
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
FAMIS Adaptive Architecture: An Introduction
10 FAMIS Software, Inc.
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
FAMIS Adaptive Architecture: An Introduction
FAMIS Software, Inc. 11
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
FAMIS Adaptive Architecture: An Introduction
12 FAMIS Software, Inc.
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.
FAMIS Adaptive Architecture: An Introduction
FAMIS Software, Inc. 13
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.
FAMIS Adaptive Architecture: An Introduction
14 FAMIS Software, Inc.
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
FAMIS Software, Inc. 15
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 Adaptive Architecture
16 FAMIS Software, Inc.
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 Adaptive Architecture
FAMIS Software, Inc. 17
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 Adaptive Architecture
18 FAMIS Software, Inc.
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.
FAMIS Adaptive Architecture
FAMIS Software, Inc. 19
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
FAMIS Adaptive Architecture
20 FAMIS Software, Inc.
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
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
(800) 774-7622 corporate