Michael Daconta | SOA: Finding a killer app
Connecting state and local government leaders
Federated query can be the killer app for service-oriented architectures.
Everyone knows stovepipes are the bane of unmanaged information technology growth. The solution-du-jour is to transition your IT systems to a service-oriented architecture ' where all major system functionality is presented as well-defined services to the entire enterprise. The difficulty lies in the word 'transition.' It takes much more than techie hype to convince bottom-line managers that this latest fad is not just that.One effective way to demonstrate SOA's value is by using a value proposition business managers can recognize: Instead of logging in to and querying multiple systems separately, how about querying them all at the same time by topic area? Every knowledge worker in your office will knowingly nod his or her head on that one.There is a disconnect between how we build IT systems and how we query them. IT systems are built to provide business services (the verbs or functions of an organization) that usually process multiple topic areas (the nouns or subjects of an organization). For example, an investigative case management system processes information on people, places, laws and incidents. An inspection system similarly processes information on people, places and inspections. A watch list system also has information on people. So, if I want a complete view of a person, I can log into each system separately, wasting time. Or I can create a single-person query and federate it across all the systems that process information about people.There is an added benefit to the latter approach: It can be done without a 'big bang' implementation, by defining a standard interface and publishing it so system owners can independently implement it when they are ready, allowing organizations to wade into an SOA.A federated query by topic area solves the fundamental impedance mismatch between how we build IT systems (by business need) and how we ask questions (by topic area).So, how do you implement federated query? There are four minimal requirements: identity management, data tier services, an enterprise service bus and an understanding of data timeliness. Since users send queries to multiple systems without logging in to each system, you must pass authentication credentials along with the query or develop enterprise roles for access to data.Second, since queries are by topic area, you need to define data tier services for basic CRUD (create, read, update and delete) operations by topic area. The Homeland Security Department's SOA Framework, created by an active cross-component working group, specifies how to create such data tier services.Third, an enterprise service bus provides a central point for service orchestration and adapter technology for easy and reliable communications with legacy systems.It is important to understand that an ESB is a logical bus and not a physical bus in the electrical-engineering sense of the word. It logically creates a message bus whereby all message consumers and producers meet at a central point to communicate.Lastly, it is important to understand that federated query is ideally suited to current and not historical or integrated information.By implementing federated query by topic area, you are on the path to flexible and robust enterprise mashups that break down stovepipes without re-engineering legacy systems. When done right, federated query is the SOA killer app.
Michael C. Daconta, former metadata program manager at the Homeland Security Department, is vice president of Oberon Associates. E-mail him at
mdaconta@oberon-associates.com.
Mike Daconta
Michael C. Daconta, former metadata program manager at the Homeland Security Department, is vice president of Oberon Associates. E-mail him at
mdaconta@oberon-associates.com.
NEXT STORY: Wyatt Kash | Pragmatism at DHS