Generational Platforms

Programming COBOL on the mainframe was the preferred platform of the generation before me. Don't get me wrong, I did my fair share. I did it, but I remember thinking that it was "my fathers platform".

I was a PC guy. When it was time to develop some new piece of software, the PC and personal OS was my starting point. I programmed in 14 different languages mostly client/server or monolithic clients running on Unix, Windows, OS/2, etc. It was obvious for me to see the benefits of this platform yet it surprised me that the last-gen often didn't get it.

In the late 1990's, I began working with people who were slightly younger than I. These people assumed that any new software built would be browser based. The Web was their platform. I remember thinking that the big thing was really Java, virtual machines, distributed computing, security sand-boxes, etc. The Web was limited in capability. Initially, I fought it - but then I got it. I laughed a bit about how I was getting old.

I'm now seeing a new paradigm emerge, once again, initiated by a younger generation. This group believes that software starts with social networks like Facebook and MySpace. It's less about the function of the software and more about the communities, relations and communications that they enable. Again, the last gen is challenged to understand the importance of this jump and many old-timers will not make the transition.

Evidence is also appearing to suggest that a second shift is occurring in parallel. That is, pervasive computing seems to have finally crossed the chasm. The iPhone has blazed a trail for a new generation applications available whenever and wherever you happen to be located. GPS enabled features brings a whole new dimension to the platform enabling scores of location based offerings.

This blog is about SOA - more specifically it is about services that enable productivity. It's often easy to get stuck in the old traps of debating stuff that doesn't really matter (REST vs. SOAP, do ESB's suck?, etc.) The exciting stuff that is going on in computing is related to the next generation platforms. The new generation doesn't care about the SOA debates - their debate is on geo-location services, cross-SaaS provisioning, etc. In essence, it isn't about SOA - it's about the next generation of services that enable pervasive computing on a social network. All of this other chatter is just last generation fools talking about stuff that only obsolete people care about.

Multiple ESB Example

David Linthicum accurately assesses my feelings:

http://weblog.infoworld.com/realworldsoa/archives/2008/07/esbs_on_trial.html

"I think Jeff may be a bit grumpy from even having to respond to this. However, once again, as I mentioned in my previous post, I'm looking for case studies and details that prove why I'm wrong, and thus why this is "silly advice." Thus far, it's been out there for 24 hours, and I've gotten zero responses. "

Now, I'm even grumpier for having to respond twice.

In Dave's own blog, within hours, of his post a gentleman responded,

FedEx Delivery is driven largely from a TIBCO-based platform. Kinkos is similarly built upon webMethods. Then they merge. It is simply not rational to think that we cannot provide FedEx with a solution to service orchestration across these 2 systems. That's the business need and what we have to solve for.

So FedEx has Tibco and WebMethods. This is interesting because my friends at SAP have told me that FedEx is a huge customer, hence, they'll probably be using the NetWeaver ESB functions as well. And when I last visited FedEx, they had purchased the BEA AquaLogic stack. My guess is that an Oracle account representative either has or will be talking to them about the virtues of Fusion Middleware and their migration plan. My guess is that they probably also have some DataPower boxes sitting around - and a few of the developers have probably downloaded Mule and are testing it out as well.

I know of no company who isn't facing the exact same issue. I'm surprised that Dave didn't run into this when he was at Mercator or Saga/Software AG. Not picking on Dave here, but it's funny, people always talk about being 'business driven, not I.T. driven', but then they make recommendations to rip out huge pieces of infrastructure to make "I.T Cleaner" because in the long run it will help business. Again, in my opinion, this is silly advice.

Linthicum on ESB's

Several people have sent me the latest Linthicum article on the back channel. People are asking if I agree...

http://weblog.infoworld.com/realworldsoa/archives/2008/07/are_esbs_hurtin.html

Dave comments:

First, if there is indeed "enterprise architecture" and an "enterprise architect" then the different divisions should not be using different ESBs, or even an ESB for that matter.

Companies are buying ESB's, will continue to buy ESB's, will buy products that are packaged with ESB's and will acquire/merge with other companies that have ESB's. They aren't going away - so yes, large companies will have to figure out how to deal with having more than one...


Dave moves on to his second point:

Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether.

In an overconfident, if not pompous manner, Dave declares himself correct. He then wants to know why a single dictator doesn't come in and end-of-life various products across business units, geographies and missions. Well, it might be a good idea for I.T. but may not be in the best interest of the business.

Personally - I see this as just plain silly advice...but perhaps, I misunderstood his point.

Silo Analysis: Key to SOA Success

At virtually every conference I attend, I hear someone declare that we need to "destroy the silos", and that SOA is the enabler. Loosely, I think of a silo as a system or information repository that solves a problem for some portion of the enterprise, while leaving other areas responsible for solving the same or similar problems on their own. Silos causes duplication of systems, business rules and data. They require multiple levels of integration and cleansing, resulting in increased maintenance and operational expenses. In general, silos are bad.

After working with a handful of organizations, it occurred to me that these companies had not performed "Silo Analysis". Almost every large organization has a number of silos that exist for a variety of reasons including:
- I.T. funding occurred by business area and each area bought/built their own (silo) systems
- Mergers or acquisitions caused duplicate (silo) systems
- Poor visibility or planning across the enterprise led to unintentional silos

---

The rumors that SOA can help are true. But before rushing down the path, organizations need to ask some important questions:
- What are our silos?
- Is there a good reason for the silos?
- Which silos do we want to end-of-life?
- Which silos can we practically kill (politics, investment, etc. )
- Will SOA lead to "silo services"?

Silo Identification
The first step to this process is to identify what silos you currently have. As I mentioned earlier, silos often mimic organizational reporting and funding structures. Here are some easy ones to look for:
- Corporate Sectors / Divisions / Business Units / Departments
- Sales Centers (Asia, Europe, Americas, etc.)
- Facilities (warehouses, manufacturing locations, distribution centers, etc.)
- Delivery Channel (Web, kiosk, mobile, etc.)

It is common for these structures to be embedded within each other as well. For instance, Acme Corporation might have duplicate CRM systems for each SBU, but also have additional CRM systems in the Asia locations of each SBU. In essence, the silo analysis has to look at combinations of the structures.

Silo Justification
Not all silos are bad. There are often good reasons why silos exist. Unique business requirements may require unique I.T. solutions. It is important to understand WHY the silo system exists but be careful not to let the 'unique business requirements' become a universal excuse for duplicate systems.

Silo Targeting
Once you've found silo systems which could be rationalized to a single service, you have to decide if their is political will power to "de-silo" the area. In many cases, if not most, it is very difficult to retire systems. The upfront cost of retiring a system is often a burden that an organization will attempt to defer for as long as possible, typically stating there are "higher priorities". The bottom line is that there will always be higher business priorities but I.T. must make the case for retiring the old.

Often the goal isn't to retire the systems but merely to create a single point of entry. In such cases, I.T. can create front end interfaces that access multiple legacy systems which cross silos. Here, we aren't retiring systems, rather we're 'bridging the silos' by standardizing the access point allowing consumers to get a single view.

Preventing Silo Services
Service Orientation offers a great mechanism to decrease the number of silos and mitigate the damage of the silos which can not be eliminated. From a rationalization perspective, SOA offers the ability to create a single "Master Service" that acts as the single source of truth for logic AND data. However, many organizations are not realizing this vision. As many have noted, services continue to be built in an ad hoc fashion resulting in JBOWS (Just a Bunch of Web Services). In almost every case JBOWS are merely silo services that were created because no one funding authority had the charter to perform silo analysis and justify a non-silo solution.

Although the 'governance' and 'cross-silo funding' problems are barriers, I believe a more tactical barrier remains. I.T. leaders are failing to teach their organizations about the silos. What are the silos? Why do they exist? Which ones are we chartered to knock down? Which will be tactically bridge? And when we do knock them down, how will we advertise that a service isn't a silo service, but rather a Master Service that crosses the divide? And perhaps most important, how do we prevent 'silo creep' in the future. Today, most software professionals have no concept of 'attaching' their unique business logic to existing services.

The Bottom Line
SOA offers a great solution to the silo problem but it will take significant political power to pull it off. Even if you are able to remove some of the silos, you'll need a plan to prevent unwanted new ones. Silo Analysis must be ingrained in the mind of every business analyst, architect, developer and governance professional. Failure to teach our next generation will lead to more silos - they'll just be written in Ruby instead of Java...

Mindreef acquired by Progress Software

Wow - how did I miss this one??

Mindreef was acquired by Progress Software!

Quietly, Progress added another set of tools to their growing SOA portfolio. Through this acquisition, Progress picks up new SOA testing at quality management solutions. Congratulations to Frank Grossman the rest of the Mindreef team.

And again, I've updated the SOA Acquisition List:
http://www.momentumsi.com/SOA_Acquisitions.html

Iona acquired by Progress

Progress Software announced the acquisition of Iona.

This move continues to round out their SOA offerings by adding registry/repository, data services, message brokering and CORBA middleware. However, as others have pointed out, this leaves Progress with significant overlap in the ESB area. I'm confident that we'll be hearing from the Progress leadership on how they intend to resolve the redundancies that exist between Artix, FUSE, SOAPStation and SonicESB.

Naturally, here is the updated SOA Acquisition List.

Gartner: Force.com Case Study

Highlights from the Force.com Case Study presenation inlcude:

MS client/server developers will quit when you move to SaaS. Hire web developers to replace them. Those people then implement innovative ideas rapidly on the SaaS platform.

Don't underestimate the need for change management training in this or any software rollout.

Developers productive within two weeks.

Easy to train up people in India to be productive on the platform.

Myth is that data on SaaS platforms is not available. Customer downloads all data from all SaaS providers onto their SAn nightly.

Very excited about their release of SAML. Seems to be standard most vendors are coalescing around.

Gartner: SOA Design Patterns

As you know design patterns describe recurring solutions to common problems in software design. And recognizing and implementing these patterns is an essential part of successful Service Oriented Design. Below are 5 SOA design patterns that Gartner analysts have observed:

1. Multichannel Applications
2. Composite Applications
3. Business Process Orchestration
4. Service Oriented Enterprise
5. Federated SOA

Multichannel Application
SOA is a perfect fit for multichannel applications. This pattern separates the back-end business logic from the front-end logic and delivers full application functionality to a maximum number of users from various channels in a minimal amount of time while reusing the same exposed services.

Strategic Planning Assumption: By 2008, more than 66% of new midsize and large interactive applications will be designed to support multichannel access, up from less than 33% in 2007.

Composite Applications
Services used in composite applications may be new service implementations, fragments of old applications that were adapted and wrapped, or combinations of the above. Two types of integration technology are essential for effective operation of a composite SOA environment: 1) integration technology behind the service interfaces, helping users wrap and adopt various pre-SOA applications; and 2) integration technology helping users assemble and monitor transactions from services.

Strategic Planning Assumption: Through 2012, the majority of SOA-style applications will be interactive composite applications.

Business Process Orchestration
Business process management (BPM) suites are the tools devoted to implementing such SOA-based multistep processing flows. The BPEL standard is often used to document the designed metadata flow model. The metadata repository ("meta-database") is used to manage the proceedings of the business process model at runtime. Some steps of the process are implemented by calling
SOA services. Other steps require human intervention.

Strategic Planning Assumption: By 2009, more than 75% of SOA applications will implement some sequencing control outside of code of the service implementations, via external BPM technology.

Service Oriented Enterprise
The SOA-based enterprise model is a step beyond composite applications. Here, all applications are perceived as components of one integrated whole. No new application is created in isolation. Each application is built from reusable components that are available for use not only in their initially intended context, but also by other clients in other contexts. Essentially, the integrated composite enterprise consists not of applications, but rather business components — each an asset of the entire enterprise.

Strategic Planning Assumption: By 2010, more than 85% of enterprises will have combined their application integration and SOA management tools and organizations.

Federated SOA
The fundamental idea behind federated SOA is to logically split the enterprise into semi-independent SOA domains (for example, reflecting the enterprise organization in terms of subsidiaries, Business Units or departments), each with its own specific SOA infrastructure, governance processes and SOA Center of Excellence. Domains are then federated (that is, integrated — usually, but not necessarily, after the fact — to enable inter-domain sharing of services) through appropriate interoperability infrastructure, governance processes and organizational settings. "SOA federation" is the process of enabling a federated SOA by establishing the
proper technical, governance and organizational capabilities.

Strategic Planning Assumption: Few large organizations are able to establish a singular architectural blueprint for their entire IT. The best practice is to endorse domain independence and allow them to differ in technology and architecture in exchange for agreement to synchronize interoperability protocols and transports. Mergers and acquisitions are clearly candidates for Federated SOA.


Posted by Tony Cook

Gartner Update: The People Side

Massive changes coming:

IT organizations are becoming change saturated. Both home and work. In next 20 years will experience the world going through peak oil production of all time.

• Medicare/Medicaid big change. Baby boomers drawing down

• Social security

• Subdivisions/developments gated by water resources.

• Question. As a manager, how do I manage the people side of these kinds of changes.

Framework of change:
Why, what, who? Are we changing.

If we can’t get the people to achieve the change then we can’t be successful.

The gating factor on change is no longer technology (has it ever been? Chris) – it is people’s ability to handle/absorb change.

If our success in technology is gated by our ability to manage the people side of change then we had better figure it out. It was very disappointing to see in the target audience here at the Gartner conference how little effect current change management initiatives have had.

Key points are that as we knew, Executive sponsorship of change is vital. However executive sponsorship isn’t just “show up for the kickoff and sign the checks”. It really must embody active involvement. Even more worrying is that, again in the audience at the session, that most attendees don’t have a “structured approach”, nor proper communication plans.

It has been our experience that change management is viewed by the technical teams as “touchy feely, unnecessary, gets in the way.” Changing that perception is a change management in its own right. That being recognized, the whole “Awareness, Desire, Knowledge, Ability and reinforcement” cycle. The presenters thesis is that all change goes through this cycle. So if we attempt to encourage the technical teams just by giving them Knowledge, we are entering the cycle too early. We need to find ways to get Awareness and Desire enshrined.

Keynote...

Notes from Roy Schulte’s session on Event Processing.

The big key here is that Gartner are positioning EDA and Client Server (Request/Response) as subsets of SOA. We use many of the same concepts (standards based, abstracted, etc.) in both of the models. Event Driven Architecture is, however, better placed for situational awareness. Much of what Roy had to say was around the handling of Complex Events – typically described as aggregations of simpler events. He also made the key observation that an event stream can, of course, kick off a number of action streams. Using an airline example where as a result of some event data being received a whole raft of operational processes is triggered – from scheduling catering to preparing the ramp.

It is also clear from Roy’s remarks that even though we had the message oriented movements of the 90s, Event processing is still emerging. The usual innovators (financial institutions especially) have jumped onto this paradigm because of a combination of regulatory needs and some major competitive advantage in an environment when market analysis in milliseconds is now the norm.

BAM – Business Activity Monitoring leading to “real time BI” or genuine situational awareness is fast becoming a real possibility when event processing approaches are applied.

Gartner Coverage!

For all the MomentumSI coverage at the Gartner show, please visit our corporate blog:

http://www.momentumsi.com/blogs.php

Gartner Conference - SOA

MomentumSI will be sponsoring and participating at Gartner’s Application Architecture, Development & Integration Summit taking place this week in Orlando, Florida. This is a significant milestone for SOA as it represents the 10th anniversary of the AADI Summit…the underlying theme being “How to deliver value in a fast-changing SOA environment”.



Our Enterprise Architecture Solutions team will be on the ground at the summit and interacting with the architects, application managers and analyst in attendance. We will be posting daily blogs regarding the hot topics encountered and engaged discussions across SOA, application and Web infrastructure… stay tuned!

The Worst SOA Presentation I've Ever Seen

Jean Jacque Dubray is outraged. He declares:

"I watched Jim (Webber) and Martin's (Fowler) presentation tonight before I went with the kids see Kung Fu Panda. The two furious have given a presentation that's got to be by far the worst presentation on SOA I have ever seen, it is not even pathetic, it reached the level of Sadness. If you wanted to turn off customers you couldn't do it better. "

I watched it. It sucks - but I've seen worst. Jim and Martin keep talking about why we shouldn't buy an ESB. The early ESB's were largely just JMS products and proprietary. In addition, the vendors positioned the ESB as the center of the software universe rather than a valuable component that has a specific function. However, the concerns I voiced five years ago on this subject have largely been addressed. Regardless, I'll agree with Jim and Martin that the ESB has the potential to do harm if over used or used incorrectly (but this is true for just about everything).

Here's my beef with the presentation. Other than the lame attacks they did on the acronym SOA, they failed to present a solution to the problem they introduced: Attacking Silos of Systems. Jim and Martin avoid this issues completely. They basically say "use our stuff from 7 years ago and you'll be fine". This includes refactoring, continuous integration, test-driven development, dynamic languages, etc. Let's be clear, these are excellent concepts that all moderns software development groups should use (if they aren't already...) but it has virtually nothing to do with the problem at hand.

If you look closely at the pitch, they fail to discuss how to not create multiple silos in the enterprise, let alone how to remove the ones that exist today. Their approach is "program better" and "increment". Fowler is an icon of modern computing and the concepts that he championed in the late 90's were brilliant. However, this stuff is crap. The promotion of "use a dumb network" and "use agile techniques" are things SOA guys agreed on 8 years ago. It's a "no shit, Martin..." kind of thing.

Now, tell me how you're going to solve the silo problem. Attacking SOA with your Same Ole Agile crap is a non-starter. These guys will have to address the real problem and quit pushing their old books. Life sure would be easy if we could all just "do REST" and then call SOA a success.

McGovern on EA-Joke

In a recent post, James "fully insured" McGovern disputes my criticism of enterprise architecture. Mostly, he was disappointed that I went after Zachman, suggesting that EA's just don't care about that anymore (which I agree). I'll add that many of them feel that FEAF and TOGAF are also a bit too 'fluffy'.

But unlike me, James seems content with the state of his Visio and Powerpoint tooling, suggesting that he and his colleagues are doing just fine.

And on the subject of "silo funding", James states, "Funding models should never look like enterprise architecture and besides they are managed by two different entities..." I'm not sure what that means. My point is that the funding model should align with your business strategy. If the strategy is to provide a seamless experience for a customer as they cross through the silos, then the funding should reflect that priority. Without proper funding, EA's become security guards with a flashlight and no gun.




BUT - the thing that struck me the most about his post was that he never actually defended the enterprise architecture discipline. This could be that he feels that it doesn't need defending. Alternatively, he could have his own frustrations with the discipline. So James, which is it?

WOA wasn't important to me last week

I spent last week working with a couple of my enterprise customers. The time was focused around the Shared Service Center (formerly known as the SOA Center). Here are the big issues that we worked on:

- Improving the help desk for production implementation problems related to shared services

- Improving the ability to perform root-cause analysis for service exceptions

- Getting funding to pay for a better staging environment

- Changing the way we engage with large I.T. programs so that they don't get bombarded by 5 different CoE's

- Changing our 'service discovery' process to make it easier to project ROI for shared services

- Identifying a new set of processes that support organizations will have to follow if the business application requires high availability: "Gold, Silver, Bronze SLA"

- Modified and communicated changes to our "Service Architecture Document" in order to provide consistency in documentation detail

In my world, SOA refers to the organizational politics necessary for an I.T. group to perform their job efficiently.

SOA has evolved from 'web services' to 'an architectural style' to 'an enterprise architecture framework' to 'a specialized I.T. lifecycle and supporting organizational design' - to 'all of the above'.

If WOA wants to encompass the aforementioned activities - I want in. Until then, WOA is just a cool thing for analysts, press and marketers to talk about. Debating the HTTP verbs might seem like 'real architecture' to some but I am genuinely concerned that a 'shiny object of misdirection' is taking our eye off of the real problems.

WOA wasn't important to me last week and it won't be next week.

Is Your Programming Paradigm HOT or NOT?

Is your programming paradigm Hot or Not????

Well, you might not agree with my observations, but here's what I'm seeing:



Real Time
Let's start at the bottom of the stack: Real Time. Due to an increase in consumer devices, wireless networks, etc. we are seeing additional requirements for new low level programming. I wouldn't call it 'explosive demand', but the area does seem to be growing.

3GL
Surely, I'll get beat up here... but that's life. I am of the opinion that the amount of 'straight 3GL' coding continues to decrease. With the maturity of other paradigms people don't need to do as much old fashion hand coding as they used to. The bulk of this work has moved up a layer in the stack (3.5 GL / App Dev).

Application Development
These days more and more people write their applications on top of some stack (Java EE, open source frameworks, .Net, etc. Typically, they are using a combination of a 3GL with DSL extensions (JSP, ASP, etc.) In recent years, we saw the big application platforms (ERP, CRM, etc.) get (mostly) migrated to one of the aforementioned stacks.

Package App Customizations
The ERP, CRM and other packaged app vendors have increased their market share (as a percent of the enterprise footprint). This has moved traditional application development to more of a 'customization' model. Power users or application configurators use a workbench to add fields to a screen, modify reports, grant user access and other basic operations. New modules or complex changes are still typically done with more of an Application Development model except that the developer is expected to use the 'business framework' that comes with the system.

Platform as a Service
Although PaaS remains in it's infancy, it is growing at a rapid pace. From a language perspective, we seem to be seeing three options:
- The first option is to create a new language (like Apex) that is PaaS friendly (multi-tenant, sandbox, governed, etc.)
- The second option is to take a current programming language and throw exceptions with people call potentially harmful features (like Google did with their Python impl)
- The third option is to let the developer program in any language they want and let them deploy it on a VM. Here, developers are typically charged for CPU time and the VM is the sandbox, thus they don't really care what you do.


In general, we're seeing more and more development move up the stack. On occasion, we have to rework the stack, so we drop back down into lower layers and then work our way back up. Ultimately, the stacks get figured out and dollars (and work) flow into the layer of the stack that is most productive.

Why Enterprise Architecture is a Joke

Enterprise Architecture is a joke. And I don't say that lightly. My goal isn't to pick fights with enterprise architects - quite the contrary. I've got huge bets on EA - my time - my career - my money. My goal is to improve it.

Anyone who has been in our industry for any period of time has heard the jokes about EA... "EA's are the guys who program in PowerPoint." Despite valiant efforts to mature the discipline by groups like IASA, the OMB, The Open Group, The Zachman Institute as well as individuals like Ambler, the discipline remains fragmented and often unproductive.

In my opinion, there are several reasons why the discipline has not matured more quickly:

1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn't happen.

2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn't a universal truth, I've witnessed my fair share of it. Those who can't architect do PowerPoint.

3. Silo Organizations promote Silo Funding. Many EA's never had a chance. They live in organizations that fund everything according to business silo's. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.

4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.

5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.

Today's enterprise architects have been given the equivalent tooling as programmers in the 1960's. I feel like I'm bashing developers who were handed punch-cards, told to program in assembler and then scolded for their lack of productivity.

The good news is that most EA's are providing significant value despite their handicaps. The great news is that smart people have identified the problem and are actively working on the solution.

Key WOA Concepts

Nick Gall clarifies a few key concepts of web architecture around the URI:

---

On Thu, May 1, 2008 at 9:09 AM, Gregg Wonderly wrote:
> I think that there are two distinct uses of URIs. There are URIs that are never
> intended to be typed by people (or at least don't need to be), and there are
> URIs that only people will type.

I couldn't disagree more strongly. We should be doing everything in our power to eliminate the distinction between human understandable and machine understandable interfaces. Thus suggesting URIs for humans be different from URIs for machines is a step in the wrong direction.

There are three important reasons to make interfaces for humans and machines as similar as possible:

Debugging: you never know when a person needs to look under the covers to see what's going wrong. Why do you think the Internet and Web emphasize ASCII text-based protocols even though they are far less efficient than binary and will rarely be seen by most people

"Show source": human readable interfaces generally and human readable URLs specifically make it easier for developers (and even occasional scripters like me) to learn from one another

Serendipity: TBL and RTF emphasize that the web is designed/engineering for serendipity. Thus you never know (and shouldn't try to guess) which URIs people will or won't want to use directly.

Our goal should be to minimize the distance between UI and API. Assuming that people will see and use all URIs is a big step in that direction.
-- Nick

---

Spot on, Nick! I love the notion of 'minimizing the distance between UI and API'...

See: http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10245

SOA Acquisitions List

I've updated the list of SOA Acquisitions:
http://www.momentumsi.com/SOA_Acquisitions.html


The new transactions were:
- Cape Clear to WorkDay
- LogicLibrary to SOA Software

I also added Sonoa Systems as a new target.

SOA Software Acquires LogicLibrary

Today, SOA Software announced the acquisition of LogicLibrary, a leading provider of software asset & reuse management. The terms of the acquisition were not disclosed.

SOA Software is best know for their integrated SOA Governance platform. The key word here being "integrated". SOA Software has both design time and run time platforms that share policy information seamlessly. For anyone who has felt the pain of integrating stand-alone registries and repositories with policy enforcement points, mediation points and web service management tools, you'll appreciate the beauty of having an integrated solution.

SOA Software is realizing a grand vision: unified governance and management of SOA across the Enterprise Lifecycle. The acquisition of LogicLibrary will give them significant depth in managing design and development assets. LogicLibrary has deep integration in IDE's and SCM's. In addition, it extends their reach into enterprise architecture by capturing reference architectures and development policies.

Through this acquisition, SOA Software is demonstrating the depth and breadth of their vision. At this point, it is unclear if the competition fails to see the vision or merely fails to execute on the vision. Regardless, SOA Software has raised the bar (again) before many of the competitors have caught up with the last bar-raising that they performed.