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.