Last week's post on Agile & SOA has generated some great conversation.  There is general agreement that Agile and SOA share values, particularly around the end goal of business responsiveness.  The question though, is how to provide that responsiveness (velocity and flexibility), in a sustainable manner (architectural integrity).  Themes that emerged in the comments were separation of concerns, increments vs. iteration, and the three C's: communication, coordination and collaboration.

Today, I'm pleased to add another voice to our conversation.  Annie Shum, a leading SOA and technology thinker, was kind enough to share her views on SOA and Agile in an email conversation, with permission to post here. 

In the first business-driven architect guest post, I’m thrilled to publish Annie Shum on Agile and SOA:

“Adding a bit more to the discussion but from a different perspective based on my favorite metaphor of SOA analogous to a set of architecture and urban city planning blueprints plus administration policies whereas developing software is more akin to building buildings, bridges, or other structures in a city.   

The former is a meta framework where city planners, building architects, policy makers, construction contractors, government officers including zoning permits etc have to come together to create a master plan through  collaboration & communication - all under some explicit as well as implicit policies & overarching governance. It’s not about the city planners dictating individual buildings but more about the overall cohesion of the city: the neighborhoods/community planning including security (courts, police buildings, fire stations etc), education (schools, libraries) and recreation (parks, zoos etc).  The relationships matter more than the individual structure to the city planners.  Meanwhile, the contractors can go ahead and build the buildings according to their own business models as long as they comply with the master blueprint of the city planner office, the zoning laws, leverage the common infrastructure based on city standards etc.

To cut to the chase, that’s what Agile vs SOA is all about. Historically, software development has been by and large project centric. To me most software development projects are still akin to “building little house on the Prairie”. Whether you use Agile or waterfall approach has both pros and cons. Obviously Agile has a lot of compelling benefits (note: I favor Agile) but only work effectively if there is constant communication between management and developers as well as clearly spelled out accountability methods to manage rogue development. Above all, transparency is critical regardless what technique is used: agile or otherwise.

In a SOA shared service ecosystem, so long as the enterprise architects act as the city planners and work collaboratively with business process owners, LOB exec, software architects, developers, database architects IT staff, capacity planners, performance analysts, etc to create a cohesive set (maybe incrementally) of architectural patterns, blueprints, what services to share, what standards to comply, what policies to follow and to specify etc,  then the software architects & developers are in theory free to implement their services (encapsulated by standards based interfaces, contracts and policies) and composite app using their technology choices and development approaches: Agile or not or more likely a mixture of agile and traditional method…

So it hinges on the SOA ecosystem cohesive architectural patterns, policies and blueprints that act as the beacon & “glue” for the enterprise. That’s why reflective modeling is so critical: it’s the closed loop modeling process from begin to end throughout the lifecycle of services that can guide this complex SOA transformation. Having a pervasive metaframework for modeling different aspects of SOA, I see Service oriented based modeling as the intermediary and the bridge connecting business & IT as well as connecting architecture patterns with software development."

Posted by brendamichelson in SOA • agile | Permalink | Comments (0) | TrackBacks (0)

• Agile Journal - Agile and SOA - July 2006
  Articles on the synergy between Agile and SOA
  (tags: soa agile)
• Agile Journal - Seven Agile Team Practices That Scale (Part I of II )
  Link to Leffingwell article referenced in Richard Leavitt's comment on Agile & SOA Post.
  (tags: agile leffingwell)
• Agile Journal - Agile at Scale: 7+7 Practices for Enterprise Agility
  Link to Part 2 of Leffingwell article referenced in Richard Leavitt's comment on Agile & SOA Post. Part 2 covers practices for Enterprise Agility, including Intentional Architecture
  (tags: agile soa)

Posted by brendamichelson in links | Permalink | Comments (0) | TrackBacks (0)

• InfoQ - Thomas Erl: Top 8 SOA Adoption Pitfalls
  "Understanding the pitfalls others have fallen victim to, puts you in a position from which you can form the extent of foresight required to chart a safer route down your own SOA roadmap. To help you get a head start, we have collected the eight most comm
  (tags: soa pitfalls erl)

Posted by brendamichelson in links | Permalink | Comments (0) | TrackBacks (0)

SearchWebServices.com has a good, short, article by Rich Seeley covering Gregor Hohpe speaking on Agile & SOA as a powerful combination.  Gregor, now with Google, is probably best known for his excellent work on enterprise integration patterns (site, book).

The article opens talking about Agile and SOA as apples & oranges:

Talking about SOA and agile development in the same breath may seem like comparing apples and oranges, says Gregor Hohpe, software architect at Google Inc., but from his point of view the terms go together like Google and search.

"Agile and SOA pair up to improve the alignment between business and IT," Hohpe told attendees at the Burton Group Catalyst Conference in San Francisco this past week. He was not being theoretical. He was talking about how Web services and applications are being developed by his employer, "one of the largest civilian computing infrastructures in the world."

The apples and oranges view comes from looking at SOA as being "an architectural style" that emphasizes how systems interact, while "agile" encompasses "a development approach" that emphasizes how people interact, Hohpe said. But in his view agile practices can help developers move SOA beyond theory.

The article goes on to point out how Agile’s emphasis on evolution, iteration, testing, learning as you go, and close customer collaboration, can help bridge the gap from SOA theory to real world deliverables.

This makes sense to me.  I always advocate starting small with SOA – the project (measurable return, low business risk), the team (good technicians, follow standards, work smart, continuous learners, influencers) and the infrastructure investment (leverage what you have, invest incrementally).  So, Agile concepts are definitely appropriate, particularly dealing with the unknown:

He urged anyone planning to start their first SOA project to not only start small but accept that they really won't know what they are doing. He urged them to accept that Agile principle "that you will know more at the end than you did at the start."

I also speak (over and over) to the importance of the “A” (architecture) in SOA for sustainable success.  Many readers of the article, and this post, might argue that Agile and SOA aren’t ‘apples and oranges’, or ‘Google and search’, but rather ‘oil and water’, because Agile skips architecture, and jumps right into design-code-test increments.

So, an interesting question then, becomes how is that architecture aspect reconciled?  Especially as you move beyond early experimentation.  How can you leverage agile development practices to implement solutions centered on an architectural strategy?  Assuming your staff isn’t loaded like Google’s. 

Right now, I have more questions than answers.  Nevertheless, I can’t help but think a healthy SOA (service model, shared infrastructure, and assembly patterns) is the perfect feeding ground for business solution development (assembly) using agile practices.  As well, I agree with Gregor, that embracing agile concepts for early SOA experimentation is smart.

I’ll definitely be doing some research and thinking along these lines.  If my schedule works out, I might even sneak out to Agile2006 for a bit next week. 

I’m very interested to hear what others think.  Have/Would you use Agile and SOA together?  How do you reconcile the ‘architecture aspect’?  Which do you start with?  As the article points out:

For the managers in the audience, he also stressed that both SOA and agile development take time for programmers to learn. He warned against the sink or swim approach where coders unfamiliar with SOA or agile practices are asked to start doing both at the same time.

Posted by brendamichelson in SOA • agile • architecture strategies | Permalink | Comments (11) | TrackBacks (2)

If you read my elemental links blog, you can skip this post.  If you don't, and you're interested in event-driven architecture, there are three new EDA related posts over there this week.  [A personal blogging best.]

Tuesday, I shared some illustrations and discussion from my "EDA and SOA: Complements and Peers" talk at the OMG SOA SIG meeting.  Wednesday, I featured a conversation with Bob Covington, CTO of Rhysome.  Today, I'm talking about StreamBase's Da Vinci Coder contest.

Posted by brendamichelson in EDA • elemental links | Permalink | Comments (0) | TrackBacks (0)

This morning, while I was searching through a box of old papers, I ran across a list of “IT Fundamental Truths” I wrote for a direct report five or six years ago.  At the time, this (immensely talented) person, who was new to IT, was frustrated by all the grey areas she kept running into.

While not every item on the following list is a winner, the essence holds up over time.  I’m curious what others think.  What would you add to the list?  Remove? 

Although I’m tempted to edit for (lack of) writing style, here is the list, exactly as first  "published”:

IT Fundamental Truths

1.  IT work is all about Compromise, some of the factors:

•        Add Value to the Business

•        Respond to ever changing business, economic and technology environments

•        We are often bounded by our legacy (assets, skills, fixed costs)

    There is enormous value in the skill of compromise, balancing challenges to create opportunity

2.  IT success relies on collaboration, alliance building, and salesmanship.  IT professionals must develop professional as well as technical skills.

3.  Negotiation is critical – for financial contracts and internal customer relationship/service level agreements, meeting truth #1.

4.   Never prematurely discount the work of those that came before you.  (See #1, 2, 15)

5.  “Big Bang” is most successful when you are starting from nothing.

6.  Anything that works in production is legacy.

7.  Continuous learners are most successful.

8.  Systems thinking ability is critical, as are the abilities to think conceptually and deal with ambiguity.

9.  Current State is a representation of assets at a point in time.

10.  Desired State is a representation of ideas at a point in time.  Desired state should plan for adaptability.  (See #16)

11.  You don’t have to know everything in advance.  You do have to know where to find the information you need.  Just in time learning.

12.  Always ask questions, brace yourself for any answer or non-answer.

13.  Best doesn’t always win at the end of the day.

14.  Think big, think broad, act pragmatically, deliver incrementally.  (See #1, 5, 6, 9, 10, 16)

15.  In requirements gathering “never” means “not yet”, “always” means “most often”.

16.  There will ALWAYS be something more important/pressing tomorrow than the most important/pressing item you are working on today.

17.  Everyday the domain you are trying to solve and the tools and techniques you are trying to solve the domain with, changes.

Posted by brendamichelson in general IT | Permalink | Comments (0) | TrackBacks (1)

• Pantero
  semantic integration, bought by Progress, used by BEA, IBM
  (tags: soa semantics coopetition)
• The 5 Patterns of Extraordinary Careers: Leadership Quiz
  This is a quick quiz on leadership. I'm guessing the most successful architectural leaders get great Benevolent Leadership scores...
  (tags: leadership quiz)

Posted by brendamichelson in links | Permalink | Comments (1) | TrackBacks (0)