I never quite fathomed the software development methodology craze that was
gripping enterprise computing when I came onto the scene in the early '90s.
In those days development teams were managing complexity and enforcing
quality via draconian software development life cycles (SDLCs).
A lot of big enterprises were using SDLCs that they had purchased as
mindshare from system integrators or tool vendors. The ones people paid for
came to be known as big-M methodologies, to denote their hegemony in the
field. There was even a meta-process to measure how refined your methodology
was. It was called CMM - the "Capability Maturity Model." CMM had five levels
of "maturity" to which enterprises aspired, with each level adding an
increasing number of artifacts, expensive tools, con... (more)
Whether you work for a very large company with thousands of services in
production or a small company with only a couple, visibility into the
performance and uptime of those services is critical. Before you start
investigating the myriad of governance products on the market, many of which
will set you back a great deal of money, let me save you some time (and
money). You can get up and r... (more)
The one thing that unifies the distributed computing style known as SOA, in
most of its manifestations, is self-describing data via the Extensible Markup
Language (XML). The benefits of XML over opaque message formats in data
interchange are well established. No matter if your focus is SOAP, REST, POX,
or syndication with RSS or ATOM, your applications will revolve around XML
processing.... (more)
Sometimes when we're faced with addressing a complex engineering problem it's
helpful to reflect on antipatterns. Doing so does more than track wrong
solutions to common problems; it also focuses the mind on the interaction of
the most important elements of the problem domain. This is true for all
engineering, not just software engineering. Suspension bridge designers know
to be on the l... (more)
I'm sure I'm like many of you in this respect: I got into engineering because
I love the idea of being able to address complex problems with a combination
of my talent, my friends' talent, and the tools that I can come up with to
make our work as easy as possible (work smart not hard!). It is this approach
that has guided me in my work as an application and technical architect. I
come to... (more)