• News from PC Magazine: Senate Committee Cuts Net Neutrality Amendment
  I suppose the only surprising part is how close the vote was 11-11. Definitely disappointing. A big threat to innovation...
  (tags: netneutrality)

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

Obviously, I'm spending a little time in 'the lounge' this afternoon.  [Great feed reader by the way - well worth the nominal $5/month fee.]

As most know, one of my soapbox topics for enterprise architects is:

The business-driven enterprise architect's responsibilities go well beyond the whiteboard. They need to deliver the architecture (tools, practices, services, and infrastructure), and roll it out to project teams.

Over the lifecycle of an architecture initiative, an enterprise architect might play a variety of roles, including strategist, evangelist, architect, project leader, developer, mentor, and enforcer.

Given that, I was glad to see a couple of recent posts highlighting the importance of architects working on the ground, guiding architecture and project realization. 

I read Mummified Architects on the CTO blog.  In a humorous manner, Ron Tolido reminds architects of a serious risk.  Technical stagnation will atrophy an architect's influence:

An architect should be an inspiring leader and mentor who visits the building place regularly and fully takes account for the designs that have been brought in. An architect should not be the mummified illustration of Peters Principle, only touching the very first part of the life cycle of a project and then quickly vanishing into history again.

This is why architects should update their technology skills over and over again, bringing them selves in sync with whatever is buzzing in real projects, in communities of practices, in universities and in the labs of technology providers.

Sounds like a busy schedule? Well, that’s what you get when you want to be an IT architect in the first place. Serves you right.

For Ron's "Signs that prove you need an IT update" see his post.

In a follow-on post, Loek Bakker calls for stoppage of feng shui architects:

Arguably the group of architects that is worst at spoiling the market for serious architects, is the group that advocates the usage of Oriental Wisdom metaphors, such as Tao, yin yang and feng shui. Probably driven by the conviction to be working on something extremely important, enlightening and difficult, oriental philosophies are used to explain balance, antagonisms (business and IT?) and controlled change.

...Even though it is hard to measure the direct value of architecture, there should be a way to measure the effectiveness of architects, to separate the chaff from the corn. Start by not trusting architects that come up with pictures of yin and yang in their presentations, or who start to talk about the emotional value of architecture. Stop these architects! Challenge them, ask questions, and do not accept anecdotes about Chinese fairy tales to explain the value of their architecture or their architecture process...

Lastly, James asks for "a litmus test on how to detect when you meet a real one vs. a faker"

Sounds like Enterprise Architect Anti-Patterns might be a good answer.  Yes, Steve Jones' SOA Anti-Patterns was on my reading list today.

Posted by brendamichelson in enterprise architecture | Permalink | Comments (0) | TrackBacks (0)

On his Science Library Pad blog, Richard Akerman likens the Enterprise Architect to a time traveler:

To be an Enterprise Architect is to live in a bit of a temporal disconnect from the rest of the world.

This disconnect is two-fold:
1) Architecture, to my mind, must be looking at the continuously receding 3-year time horizon.
That creates the critical bridge between the day-to-day and month-to-month activities of the organization, and the organization's stated 5-year strategic plan.
2) The people in your organization may not even be living in the present.  They may have a technological viewpoint that lags several years behind.

So you're in the meeting room in 2006, and you're trying to have a conversation based on where you think things will be in 2009, meanwhile, the organization is still back in 2001.

At the end of his post, Richard poses some questions I wanted to pass along to readers:

Anyone else have ideas on key metrics to qualitatively or quantitatively assess the success of the EA?

Any thoughts on bridging the time warp between 3 and 5 year strategic visions and the day-to-day of project and operations execution? 

Better ideas for moving the organization's technology thinking forward, rather than just "inform and be ready"?

If you have thoughts on the above, please jump over to Richard's post.

. 

Posted by brendamichelson in enterprise architecture | Permalink | Comments (0) | TrackBacks (0)

• WebServicesStandards
  WS-* standards in poster format from innoQ; last revised sept 2005... informative and scary
  (tags: soa ws-*)

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

• James Governor's MonkChips: Guestpost: On Hardware As A Service, engines as services, and Real SOA
  Some good thinking on what the 'service-oriented world' will become. XaaS: Software as a Service, Information as a Service, Business as a Service, and yes, Hardware as a Service. Coming (eventually) to a service ecosystem near you.
  (tags: HaaS SaaS IaaS BaaS servicegrid redmonk)
• Tim Berners-Lee on Net Neutrality: This is serious
  "I hope that Congress can protect net neutrality, so I can continue to innovate in the internet space. I want to see the explosion of innovations happening out there on the Web, so diverse and so exciting, continue unabated."
  (tags: netneutrality timbl)
• TechCrunch » Blog Archive » PostApp launches WidgetBox, a marketplace for widgets
  Interesting ... "PostApp will manage the process of turning web services into widgets that bloggers, social network users and others can insert into their pages. Outside developers will create web services, submit them to PostApp for transforming into wid
  (tags: soa servicegrid web2.0 widgets)

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

Last Friday, I asked if readers were interested in collaborating on questions related to business-driven architecture. This was inspired by a comment from James. Continuing the community-driven theme, I shared a suggested starter question from Mark G.

So one question I would love to hear discussion on is how to prepare your IT organization for Service Orientation. I am curious to see how others are approaching this or not approaching it. I do see it as a challenge for your typical corporate IT shops as oppose to software vendors. What do you think? Is this a big issue for your shops? My gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA. Is this something worth discussing/addressing? Is everyone even looking at SOA now that the hype is at fever pitch?

Some readers sent emails indicating their interest, while others jumped right in. In this post, I'm wearing my host/facilitator hat. I intend to highlight some of the conversation points, provide a chronological tracking of the conversation across the participating blogs (posts, comments and trackbacks) to ease new participant entry, and ask some questions to keep things going. In the spirit of keeping the conversation connection, I'll throw trackbacks from this post. I invite all practitioner readers to participate in this conversation. Here at BDA, on your own blog (please throw me a trackback), and via comments on the community member blogs.

But first, a little housekeeping. Elizabeth Book, ebizQ's editor-in-chief, responded "Absolutely" re: publishing any BDA community generated content. As well, to ease our interaction, the ebizQ technical team added permalinks for individual comments, and you can now subscribe to a comment/trackback feed. [Also available in the Subscribe section of my right sidebar.]

The Conversation: How to Prepare Your IT Organization for Service-Orientation?

[Please note the emphasis below was added by your facilitator]

Todd started the conversation on Tuesday. He disagreed with Mark's "gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed of governance and discipline to have a run at SOA."

Todd stated:

"I think a strong background in these technologies will assist in building service-oriented applications, but I don’t think it will go very far in yielding service-oriented architecture. The reason for this is that as long as all of the IT effort remains within the constraints of a single project, the organization will never understand it means to be a service provider...

...To me, the ability for an organization to succeed is going to be highly dependent on their ability to communicate, collaborate, and manage the service lifecycle, independent of whatever technologies are involved. I had the opportunity to comment about this in the a recent ZapThink podcast."

Mark replied:

It makes me think that when addressing SOA conversations, it’s important to distinguish between the technical aspect and the business aspect.

One thing an EAI competency center helps with is a larger view of the business as well as the various projects within an IT organization. These centers often have a much better view of the world than individual development groups within an IT organization...This one group however cannot transform the entire IT organization however, which is the thought behind my original post. How do you get your IT organization to that state which you are describing?

Anil John joins next, adding important points on SOA being about the business, and the tie between SOA governance and enterprise architecture:

As a technologist it pains me to admit this, but SOA is NOT about technology. It is among other things, identifying the capabilities that are offered by the business unit, having a clear understanding of the processes that make up those capabilities, and making those processes available for reuse via standardized interfaces to the enterprise at large.

...if the culture already has a good governance process in place as part of its Enterprise Architecture, adding the bits that enable governance for SOA is an incremental addition and not a big culture shift. And this addition very much improves the chances of success of the SOA implementation, given that lack of governance has been cited as one of the prime reasons for the failure of SOA implementations.

Todd and Anil are in agreement on a business-first approach. Todd then shares some (good) business process analysis questions to jump start developer's thinking:

1) What services does your solution use / expose?
2) What events does your solution consume / publish?
3) What business process(es) does your solution support?

Knowing Todd, I'm pretty certain "services" in question #1 refers to abstract business services, rather than technical implementations.

At this point, Mark returns here, agreeing with Todd and Anil that a critical step in preparing an organization for SOA is understanding and focusing on the business. However, he brings up a good point, that IT still needs to deliver:

Is it possible to focus on the business but forget that at the end of the day you still have to deliver what you promised? This would be the loosely coupled, reusable and agile services that make up that business process.

The reason I asked is that I have seen many EAI and EDA architectures fail because either the industry/vendors or the IT shop trivialized the technology piece. It's one of those if it were easy then everyone would be doing it. I can tell you that loosely coupled, reusable, agile services are not trivial to most corporate IT shops.

Mark then suggests a natural fork for the conversation:

So maybe the conversation should fork into how do I get my IT organization more involved with the business to really understand it? And how do I make sure that my IT organization can deliver the services that will enable that understanding? What do you think?

Anil and Todd both chime in on steering clear of business process paralysis. Anil offers a mixed top-down bottom-up approach:

Approaching SOA from both the Top-Down/Business Process perspective as well as the Bottom-Up/Service Factoring perspective allows for the identification of the re-usable aspects in a business process and to realize that re-usability using the service implementation technology of your choice. In short, this helps you build the right type of services that are reusable across the Enterprise.

Todd comments on finding the right scope:

Bottom-up efforts are more easily embraced because the starting point is well defined. Top-down efforts, are not so easily embraced. How high up do you go? I think this depends on your resources and the ability of those with business knowledge to contribute. You need to look broader than the bottom-up project at hand, but beginning at enterprise may be too far away to be practical. If the answer was easy, we’d all have done it by now.

Potential Questions to Continue the Conversation:

1. Yes, understanding the business is critical in preparing an organization for SOA. But what else? As Mark asks, how can he ensure his organization is ready to deliver?

2. And the other fork from Mark: "How do I get my IT organization more involved with the business to really understand it?"

3. What tools and/or methods are effective for top-down, bottom-up business and service modeling?

4. How about that "elusive" governance? How do you sell Governance to IT and Business Leadership? Where do you get the money for people, process and tools? How do you convince people "Governance is good for you" rather than "Governance is a roadblock"?

I'd be remiss if I didn't thank our contributors to date. Great thinking. Also, I want to emphasize this is open participation, the more brain power the better!

Posted by brendamichelson in SOA • bda community projects • business driven architecture | Permalink | Comments (4) | TrackBacks (2)

• OMG-and-the-SOA.pdf (application/pdf Object)
  "new OMG group, the SOA Special Interest Group... coordinate SOA efforts within the OMG and between the OMG and other SOA standards groups, including W3C, The Open Group, and OASIS. ...as SOA specific modeling approaches and best practices stabilize, OMG
  (tags: omg soa methodology)
• JBoss acquires enterprise-ready ESB
  JBoss expedites ESB thru acquistion. via MarkG at Darth.net
  (tags: jboss esb opensource)

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

Posted by brendamichelson in business driven architecture | Permalink | Comments (1) | TrackBacks (5)

The May issue of ACM Queue has a great interview of Amazon’s CTO Werner Vogels, by Microsoft Technical Fellow Jim Gray.  In the interview, they discuss Amazon’s technology transformation from monolithic web applications to a service-oriented architecture.  This isn’t just a technology transformation story, but also a business one.  As Amazon shifted their application architecture to a services approach, they were able to shift from being an on-line retailer, to a business services and technology platform company – that just happens to have an on-line retail business with 55 million customers.

In the interview, they cover a lot of ground: why SOA?, the resulting solutions, lessons learned, use of standards, use of tools, developers as artists, architects as creative thinkers, business strategy alignment, innovation, and relentless customer focus. 

In this post, I want to call-out four topics (and corresponding conversation) that I found especially interesting.  The full article is available (free) here.    

Why SOA?  Amazon realized their traditional web applications and database access/scaling approaches were constraining business growth.  Not just in terms of customers, products and categories, but also in terms of new business offerings. 

WV Growth is core to Amazon.com's business strategy, and that has had a significant impact on the way we use technology: growth through more categories, a larger selection, more services, more buying customers, more sellers, more merchants, more developers, increasing the different access methods, and expanding delivery mechanisms. The impact has been on many areas: larger data sets, faster update rates, more requests, more services, tighter SLAs (service-level agreements), more failures, more latency challenges, more service interdependencies, more developers, more documentation, more programs, more servers, more networks, more data centers. A large part of Amazon.com's technology evolution has been driven to enable this continuing growth, to be ultra-scalable while maintaining availability and performance.

Amazon.com started 10 years ago as a monolithic application, running on a Web server, talking to a database on the back end. This application, dubbed Obidos, evolved to hold all the business logic, all the display logic, and all the functionality that Amazon eventually became famous for: similarities, recommendations, Listmania, reviews, etc. For years the scaling efforts at Amazon were focused on making the back-end databases scale to hold more items, more customers, more orders, and to support multiple international sites. This went on until 2001 when it became clear that the front-end application couldn't scale anymore.

JG Was that performance scalability, or was it manageability, or facilities?

WV The many things that you would like to see happening in a good software environment couldn't be done anymore; there were many complex pieces of software combined into a single system. It couldn't evolve anymore. The parts that needed to scale independently were tied into sharing resources with other unknown code paths. There was no isolation and, as a result, no clear ownership.

At the same time, there was continued difficulty in the back-end database scaling effort. Databases—and by that time we were using several databases—were a shared resource, which made it very hard to scale-out the overall business. So both the front-end and back-end processes were restricted in their evolution because they were shared by many different teams and processes.

We went through a period of serious introspection and concluded that a service-oriented architecture would give us the level of isolation that would allow us to build many software components rapidly and independently. By the way, this was way before service-oriented was a buzzword.

Simple Roots, Complex Applications.  Amazon has a simple approach to services, which allows them to recombine those services in a variety of applications and business offerings.  Those applications and business offerings include: Amazon’s retail customer website, Amazon’s Seller Marketplace, AWS, and an e-commerce platform for the creation of independent e-commerce sites, such as Target and Sears Canada.

WV  For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there's no data sharing among the services.

Over time, this grew into hundreds of services and a number of application servers that aggregate the information from the services...

…The big architectural change that Amazon went through in the past five years was to move from a two-tier monolith to a fully-distributed, decentralized, services platform serving many different applications. A lot of innovation was necessary to make this happen, as we were one of the first to take this approach. Operating such a diverse set of services at this scale is not something that many people have done before, especially not with the kind of isolation that we wanted to achieve.

It has been a major learning experience, but we have now reached a point where it has become one of our main strategic advantages. We can now build very complex applications out of primitive services that are by themselves relatively simple. We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration.

Lessons Learned.  So often, we think of services and performance degradation.  I found Amazon’s story compelling regarding a different take on that point. 

WV The first and foremost lesson is a meta-lesson: If applied, strict service orientation is an excellent technique to achieve isolation; you come to a level of ownership and control that was not seen before. A second lesson is probably that by prohibiting direct database access by clients, you can make scaling and reliability improvements to your service state without involving your clients. Other lessons are related to how you access services: If you want to be able to aggregate services easily, if you want to insert advanced infrastructure techniques such as decentralized request routing or distributed request tracking, you need a single unified service-access mechanism.

In addition, Werner offers insights on development impact.  The “You build it, you run it” is worth thinking about.

WV Another lesson we've learned is that it's not only the technology side that was improved by using services. The development and operational process has greatly benefited from it as well. The services model has been a key enabler in creating teams that can innovate quickly with a strong customer focus. Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality, to architecting it, to building it, and operating it.

There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

Later in the interview, Werner speaks to the importance of testing.  I had a conversation with Solstice a couple of weeks ago on this very topic. 

WV One of the biggest challenges is developing at this large scale. How do you make sure that developers are productive in this large distributed service-oriented architecture? If you have this decentralized organization where everybody is developing things in parallel, how can you make sure that all the pieces work together as intended, now and in the future? An important part of that is, for example, testing. How do you test in an environment like Amazon? Do we build another Amazon.test somewhere, which has the same number of machines, the same number of data centers, the same number of customers, and the same data sets?

How do I test against this pair of jeans with that size, which just happens to be out of stock but will be back in stock two days from now, such that the customer e-mail interaction can be tested correctly? How do I test that with the new version of the offer-services that will roll out next week on the Japan Web site but with a browser that is not complete in displaying the Kanji characters?

These are very hard questions, and we have no simple answers. Testing in a very large-scale distributed setting is a major challenge.

Innovation.  I think this point is critical.  Service-orientation (loose coupling, mix and match, non-invasive changes) provides a platform (ecosystem) for experimentation and business innovation. 

WV If an idea is deemed worthy of investigation, we exploit our service development approach to scope and prototype the idea quickly. With a new radical service, you try to go into prototype mode pretty quickly, and then you start iterating on that until you feel that you understand your business problem. The small-team concept means that you have a continuous feedback loop where you try to understand the impact for the customer.

That's in general how requirements are being refined, with the customer in the loop. It is also very important to try to determine at the outset what the success criteria should be, and how they can be measured.

This fast response to new ideas is enabled through the loosely coupled services model, both in technology and at the developer and operations level. From the outside, the services in our platform may appear chaotic, but chaotic in a good sense—in that we try not to impose a rigid structure on the different functional pieces, but we expect there to be order when looking at it from a different dimension. Thinking about this whole system as a big deterministic system would be unrealistic. Life is not deterministic, and a large-scale distributed system such as Amazon has many organic and emerging properties that can come to life only if you do not constrain it.

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

• EssUP_NewIntro.pdf (application/pdf Object)
  2 page intro to Ivar Jacobson’s Essential Unified Process. EUP relies on “Separation of Concerns (SOC or aspect-oriented thinking).” “…5 foundation practices, and three supporting practices…Each practice can be developed, adopted and applied
  (tags: methodology soa agile aspect)

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

• EssUP_NewIntro.pdf (application/pdf Object)
  2 page intro to Ivar Jacobson’s Essential Unified Process. EUP relies on “Separation of Concerns (SOC or aspect-oriented thinking).” “…5 foundation practices, and three supporting practices…Each practice can be developed, adopted and applied
  (tags: methodology soa agile aspect)

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

• dropping knowledge :: the drop
  "Asking questions is fundamental to the practice of dropping knowledge. There is no better way to initiate a dialog than with a question, no better way to challenge conventional thinking, discover new viewpoints and stimulate fresh ideas." The Drop weblog
  (tags: dropping_knowledge)

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