Conmergence

Thomas Erl Sends a Pointer to the Public SOA Design Patterns Review

<ed.note>Thomas writes:

Just wanted to let you know that a galley of the new soa design patterns book is being sent out to you. The design patterns are also published at www.soapatterns.org as part of an public, industry-wide review. Please refer any of your colleagues to this site that may also be interested in participating.

Best,

Thomas

Ed. - There is much more content at the site but I provide a snippet below:</ed.note>

From the site:

NOTE: The following content is part of an industry-wide SOA design patterns review that is being carried out until January 31, 2008. This content is still subject to change and is scheduled to be finalized by March, 2008.

The Public SOA Design Patterns Review

This site is currently dedicated to a public review of 60 design patterns from the upcoming book "SOA Design Patterns" by Thomas Erl.

The author is collecting feedback, opions, contributions, and validation from professionals and practioners from around the world in order to finalize the manuscript for a scheduled publication in March, 2008.

SOAPatterns.org will subsequently remain a community resource site, containing revised, concise descriptions of all SOA design patterns and allowing for new design patterns to be published and reviewed on an on-going basis.

Demand Distributed Homeshoring First [ Update ]

<ed.note>Birmingham, AL and Oklahoma City, OK rate well among the Top 50 Emerging Outsourcing Cities. Indian Tutors Teach U.S. Kids Math over the Internet. Jim Ware and Charlie Grantham size up distributed work in the future of work.

Older Post: Anthony O'Donnell, of Insurance & Technology, blogs on "Offsite But Not Offshore: Promoting a Domestic Outsourcing Alternative". My response rant ( with a typo fixed ): "Anthony: These insights are helpful as far as they go. But the thing to which everyone seems to be oblivious ( or are acting as if ) is that with global broadband building out, content management systems, VOIP, wikis, code repositories, online project management applications, IM, web cams, virtualized server clusters, etc. there is no need for a DEVELOPMENT CENTER at all. What the fed and states rural economic development folks, the institutional disabilities advocates and pseudo-green politicians don't seem to get is that we don't need to commute to one place ( wasting gas ). The open source movement ( which is kicking butt in the IT sector and changing the paradigm of HP, IBM, SUN, etc. ) teaches us that talent can work just fine on the distributed, digital enterprise known as the internet. It is the iddatarate management structure which refuses to reduce their workflows to metrics and measurable goals ( fear of the phrase "Would you like fries with that?" ). It is time for institutional shareholders to begin demanding during conference calls the steps firms are taking to digitize their business processes so that they can be fulfilled from anywhere in the world with a decent pipe."

Older Post:
If you see the CompeteAmerica PR piece you'll note the argument that "The Sanders Amendment will accelerate outsourcing and undermine U.S. economic growth" -- so basically CompeteAmerica's argument is "Give us H-1bs or we'll outsource the jobs anyway."

What I don't understand is why neither major politcal party is being called on the carpet by activists for not promoting a domestic telework economy as a National Economic Security Issue given the attendant "green" benefits caused by reduced unnecessary work-related commuting. Now I realize that this could be just another mechanism to offshore work ( though this reality is just the logical companion of a "meritocracy" mindset ) but it is also a mechanism to bring folks from rural workforces and high tech rural economic development projects into the mix ( as well as the 70% of folks with disabilites who are unemployed and who just can't get to the work place for lack of accessible transportation ). While I tend to knock Tennessee's Governor Bredesen on his short-term disabilities-related healthcare strategies, I must commend his work toward building a "The Trail to Innovation". I don't have anything "against" Indian or Chinese workers, but we do need to encourage a US workforce which will build the skills to be able to compete for gigs in other nations cyberly -- thus bringing that capital into this economy instead of the current outflow trend.

My personal bias is that "Demand Distributed Homeshoring First" would be more discerning rallying cry, however. The real question is why can't software development firms and corporate America IT shops seem to get past geolocking their positions in certain locales? How can you maintain any kind of credibility by forcing the development folks producing distributed development tools to all be on the same campus ( the eat your own dogfood axiom )? One reason, I strongly suspect, is that managers are aware that once they reduce their project goals to quantifiable metrics ( necessary to make distibuted work successful ) they, too, will be outsourced or automated out of their positions.

American employers and stockholders need to look seriously at the premise that there isn't an IT labor crunch, but rather, an IT laborer shortage in certain US geographies. The REAL PROBLEM is that many IT jobs ARE NOT LOCATION DEPENDENT, but managers refuse to trust their employees to telecommute. Almost all of the job vacancies I have seen recruiters pitch as difficult to fill are in the category of "you must relocate to a given city" with hiring managers refusing to give any credence to the IT worker's perfect understanding that the probability is pretty high that one week after they move their family to Silicon Valley, Boston, Redmond, wherehaveyou, that the position will be offshored to India. The irony is that now the Indian firms are racing to replicate the geolocked development center model in the US.</ed.note>

Index of Thomas Erl's "SOA: Principles of Service Design,"

Publisher: Prentice Hall
Pub Date: July 18, 2007
Print ISBN-10: 0-13-234482-3
Print ISBN-13: 978-0-13-234482-1

Copyright
Praise for This Book
Service-Oriented Computing Series
Preface
Acknowledgments
Chapter 1. Introduction
Section 1.1. Objectives of this Book
Section 1.2. Who this Book Is For
Section 1.3. What this Book Does Not Cover
Section 1.4. How this Book Is Organized
Section 1.5. Symbols, Figures, and Style Conventions
Section 1.6. Additional Information
Chapter 2. Case Study
Section 2.1. Case Study Background: Cutit Saws Ltd.
Part I: Fundamentals
Chapter 3. Service-Oriented Computing and SOA
Section 3.1. Design Fundamentals
Section 3.2. Introduction to Service-Oriented Computing
Section 3.3. Goals and Benefits of Service-Oriented Computing
Section 3.4. Case Study Background
Chapter 4. Service-Orientation
Section 4.1. Introduction to Service-Orientation
Section 4.2. Problems Solved by Service-Orientation
Section 4.3. Challenges Introduced by Service-Orientation
Section 4.4. Additional Considerations
Section 4.5. Effects of Service-Orientation on the Enterprise
Section 4.6. Origins and Influences of Service-Orientation
Section 4.7. Case Study Background
Chapter 5. Understanding Design Principles
Section 5.1. Using Design Principles
Section 5.2. Principle Profiles
Section 5.3. Design Pattern References
Section 5.4. Principles that Implement vs. Principles that Regulate
Section 5.5. Principles and Service Implementation Mediums
Section 5.6. Principles and Design Granularity
Section 5.7. Case Study Background
Part II: Design Principles
Chapter 6. Service Contracts (Standardization and Design)
Section 6.1. Contracts Explained
Section 6.2. Profiling this Principle
Section 6.3. Types of Service Contract Standardization
Section 6.4. Contracts and Service Design
Section 6.5. Risks Associated with Service Contract Design
Section 6.6. More About Service Contracts
Section 6.7. Case Study Example
Chapter 7. Service Coupling (Intra-Service and Consumer Dependencies)
Section 7.1. Coupling Explained
Section 7.2. Profiling this Principle
Section 7.3. Service Contract Coupling Types
Section 7.4. Service Consumer Coupling Types
Section 7.5. Service Loose Coupling and Service Design
Section 7.6. Risks Associated with Service Loose Coupling
Section 7.7. Case Study Example
Chapter 8. Service Abstraction (Information Hiding and Meta Abstraction Types)
Section 8.1. Abstraction Explained
Section 8.2. Profiling this Principle
Section 8.3. Types of Meta Abstraction
Section 8.4. Measuring Service Abstraction
Section 8.5. Service Abstraction and Service Design
Section 8.6. Risks Associated with Service Abstraction
Section 8.7. Case Study Example
Chapter 9. Service Reusability (Commercial and Agnostic Design)
Section 9.1. Reuse Explained
Section 9.2. Profiling this Principle
Section 9.3. Measuring Service Reusability and Applying Commercial Design
Section 9.4. Service Reuse in SOA
Section 9.5. Standardized Service Reuse and Logic Centralization
Section 9.6. Service Reusability and Service Design
Section 9.7. Risks Associated with Service Reusability and Commercial Design
Section 9.8. Case Study Example
Chapter 10. Service Autonomy (Processing Boundaries and Control)
Section 10.1. Autonomy Explained
Section 10.2. Profiling this Principle
Section 10.3. Types of Service Autonomy
Section 10.4. Measuring Service Autonomy
Section 10.5. Autonomy and Service Design
Section 10.6. Risks Associated with Service Autonomy
Section 10.7. Case Study Example
Chapter 11. Service Statelessness (State Management Deferral and Stateless Design)
Section 11.1. State Management Explained
Section 11.2. Profiling this Principle
Section 11.3. Types of State
Section 11.4. Measuring Service Statelessness
Section 11.5. Statelessness and Service Design
Section 11.6. Risks Associated with Service Statelessness
Section 11.7. Case Study Example
Chapter 12. Service Discoverability (Interpretability and Communication)
Section 12.1. Discoverability Explained
Section 12.2. Profiling this Principle
Section 12.3. Types of Discovery and Discoverability Meta Information
Section 12.4. Measuring Service Discoverability
Section 12.5. Discoverability and Service Design
Section 12.6. Risks Associated with Service Discoverability
Section 12.7. Case Study Example
Chapter 13. Service Composability (Composition Member Design and Complex Compositions)
Section 13.1. Composition Explained
Section 13.2. Profiling this Principle
Section 13.3. Composition Concepts and Terminology
Section 13.4. The Complex Service Composition
Section 13.5. Measuring Service Composability and Composition Effectiveness Potential
Section 13.6. Composition and Service Design
Section 13.7. Risks Associated with Service Composition
Section 13.8. Case Study Example
Part III: Supplemental
Chapter 14. Service-Orientation and Object-Orientation: A Comparison of Principles and Concepts
Section 14.1. A Tale of Two Design Paradigms
Section 14.2. A Comparison of Goals
Section 14.3. A Comparison of Fundamental Concepts
Section 14.4. A Comparison of Design Principles
Section 14.5. Guidelines for Designing Service-Oriented Classes
Chapter 15. Supporting Practices
Section 15.1. Service Profiles
Section 15.2. Vocabularies
Section 15.3. Organizational Roles
Chapter 16. Mapping Service-Orientation Principles to Strategic Goals
Section 16.1. Principles that Increase Intrinsic Interoperability
Section 16.2. Principles that Increase Federation
Section 16.3. Principles that Increase Vendor Diversification Options
Section 16.4. Principles that Increase Business and Technology Domain Alignment
Section 16.5. Principles that Increase ROI
Section 16.6. Principles that Increase Organizational Agility
Section 16.7. Principles that Reduce the Overall Burden of IT
Part IV: Appendices
Appendix A. Case Study Conclusion
Appendix B. Process Descriptions
Section B.1. Delivery Processes
Section B.2. Service-Oriented Analysis Process
Section B.3. Service Modeling Process
Section B.4. Service-Oriented Design Processes
Appendix C. Principles and Patterns Cross-Reference
Additional Resources
About the Author
About the Photographs
The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Inside Front Cover
Inside Back Cover
Index

15th Enterprise Architecture Practitioners Conference, July 23-25, Austin, TX

Agenda here.

The Era of the Inclusive Leader

By Chuck Lucier, Steven Wheeler, and Rolf Habbel, strategy+business

As turnover levels off, our annual CEO succession study shows chief executives and their boards adopting new survival strategies.

Welcome to the era of the inclusive chief executive officer — a very different species from the “imperial” CEOs who roamed the corporate landscape not so long ago. Whereas imperial CEOs answered only to themselves, the power of today’s CEO is not as absolute: Boards of directors are becoming more critical and more closely involved in setting strategy, and are far more likely to insist that CEOs deliver acceptable shareholder returns (as well as demonstrate ethical conduct). Indeed, the data indicates that boards are increasingly prepared to replace CEOs in anticipation of disappointing future performance, instead of merely as punishment for poor past performance. At the same time, large shareholders like hedge funds and private equity firms are taking a more active role in decisions that were once the sole purview of the CEO.

Gartner Application Architecture, Development & Integration Summit, Nashville, TN Gaylord Opryland Resort & Convention Center, 11-13 June 2007

Agenda here.

This One's For You, Mr. Anderson!

<ed.note>Dana points me to Howard's article where he writes "Open source is not a movement; it's a religion" -- to which I return with the intellectually pleasing: "So! -- and unbridled capitalism isn't a religion? Isn't there something about Mammon worship in the holy writings somewhere?" In reality, Howard is anxious because publishing is being open sourced (democratized|meritocratized|interoperantized|transparentized), too. With all the media consolidation happening at one end of the content spectrum and the paid blogging/youtube phenomena on the other -- he has to defend the paradigm in which he feels the most comfortable competing. Ok, let me be serious a bit and look at his analysis: a point he doesn't mention factoring in is that most "mainstream, commercial IT shops" are already mixed sourced shops... because of quality concerns... quality which results from collaboration and transparency. As I opined in response to Dana's piece -- The "Problem" with Open Source is, at the end of the day, it teaches the users/software consumer and institutional stock holders that the coder is more valuable than the CEO. Coincidently, it is teaching at a time, when in proprietary software the coder is being offshored and down-salaried, and the C-Suite is receiving a bonus for the "jump in productivity." And yet, on the third hand, it is at a time when C-Suites are under increased share holder pressure to tie pay to performance.</ed.note>

SOA Class War, Part Deux

"2007 Top Five Total Rewards Priorities", Deloitte Consulting

Concern about sustaining a high-quality workforce has reached an all time high, creating a growing tension between cost control and talent management... For the first time, respondents with more than $1 billion in revenue ranked “attracting, motivating, and retaining talent” as a higher concern than “control of health care costs.” This is a clear divergence in the top priorities between larger and smaller companies.

See also "Revolt in the Boardroom, The New Rules of Power in Corporate America" by Alan Murray

Outsourcing the C-Suite [ Tweaked and reposted -- was: Ralph Szygenda believes that the high-tech industry can learn from the auto industry ]

<ed.note>The services and support industry no longer requires an overpaid, iddatarate management strata -- since it can easily be replaced by a webbed database, wiki or now, finally, outsourced. Shareholders, especially with the rise of "activists" coupled with the blogosphere, will get wise “that globalization hasn't gone far enough.” This is because there is no sphere in business to which Szygenda's "standards" do not apply and those standards lead to automation and outsourcing and real-time accountability ( interoperancy ) on a cost per unit basis. Adoption of service oriented architecture, the rise of financial services straight thru processing, and the push for transparent open book management is set to ignite a very interesting class war. Though the new money provided by increased productivity ( read: IT employees, whose data aggregation and process re-engineering produced the value ) produced has gone straight to "C" bonuses, rather than employees or stockholders, "C's" still feel a need to pull stuff like this and this.</ed.note>

C-Suites, Czars and Cybercriminals

<ed.note>Apparently the bad guys compensate their IT talent and the good guys wish they did. If only there were some obvious, salient lesson the markets ( who decide compensation via stock ownership and pressure on boards -- active or passive ) and governments could draw from this inscrutable enigma.</ed.note>

Stephen Swoyer on [Stupid] People, Process, SOA; Me on SOA and the Outsourcable [Update]

9/19/2005 By Stephen Swoyer, "SOA Fatigue: It’s the People and Processes, Stupid", ADTmag.com

<ed.note>I rant here because Leavitt, Brailer and all those around NHIN have other factors to tackle in addition to interoperability.</ed.note>

Large-scale service-enablement is a doomed enterprise for one important reason, some codejockeys argue: bureaucratic infighting.

It’s not that the technology vision espoused by SOA advocates and their fellow travelers isn't viable—although most developers also question just how viable pervasive service-enablement actually is—but that the loosely coupled services infrastructure envisioned by most proponents will almost certainly be plagued by a very familiar array of people and process issues.

Call it turf wars revisited, or SOA petty fiefdom, of a sort.

“There is a 4-year old system in place at Wells Fargo that…interacts with multiple external credit-scoring companies to make granting decisions,” explains Jonathan House, an IT director with Amirsys, a medical technology company. Except that on the path to composite app bliss, reality got in the way. “Each of the organizations that we interacted with had their own proprietary software for accessing credit-score information. None were compatible with each other, and none were Web-services based,” explains House, a former programmer with Wells Fargo.

House makes this point to illustrate the implications of external turf wars: namely, that third-party credit-score providers have little or no incentive to accommodate the service-enablement agendas of companies such as Wells Fargo. “We built the ‘credit-score’ interface that the application used, along with four different implementations of that interface for each of the vendors we were working with. In two cases we asked the vendor to write the interface code for us, and offered to pay them to simplify our job, and in both cases we were turned down flat because they saw that the interface design made their service a commodity.”

<ed.note>SOA will bring to a head the corporate class war (you feel the rumbling!) between those who are outsourcable and those who are not. Will the outsourcable organize? Will they take global work condition requirements seriously (to force a "level playing field")? Will they buy their own lobbyist-senator package? Will they sue institutional investors who reward the unoutsourcable? Will they continue to practice only "whine therapy"?

Quick: it's national business exec quiz time. Clear off your desks -- with the exception of your laptop -- now diagram your business' key processes. Just sketch them. Use some standard biz tool (UML is a media darling). You have ten minutes. Ten days? Ten weeks? Ten consultants? What Mr. Swoyer was too diplomatic to say was "It's the stupid people in the process!" America's big "unexposed" vulnerable underbelly is that even if management wanted to SOA they don't have the skills to accomplish it. And they know if the org figures that out, they'll be outsourced or down-salaried.

Now the populist tag line here would be: "Maybe the folks in the process aren't so stupid after all!" But while rhetorically pleasing, it doesn't remove the reality that if your org doesn't SOA your processes some competitor will -- just not in a business culture or pay rate in which you feel comfortable operating. [Update: "In Tech Boards - The New Secret to Success in Bridging Business and IT" Michael Liebow describes the new approach companies such as FedEX, Mellon Financial Corp, PNC Financial Services Group and Pfizer Inc. have taken to get around that unpleasant reality that biz execs don't have the necessary tech skills to deal with a distributed, digital enterprise economy.]

Now the folks from Wells Fargo were right -- House's proposal would have commoditized their service -- but they would have at least had some ownership in the process. The WF folks thought they were being smart by avoiding the evitable. Now if their service is duplicated and commoditized and they are disintermediated, they'll be locked out of the process.

For organizations, obviously, the challenge is figuring out first and best what can be created by combining bizproc1 and bizproc2 (...bizproc127) when these services have never been combined before. Or at least not well. And anticipating the gaps in the SOA palette which will need to be filled in. And then filling the gaps. And applying the processes. Fast. Wash. Rinse. Repeat.>.

The one "stupid people in the process" element few mention is DIRTY DATA. When every data source is validated against every other data source, what happens when a trusted source gets it wrong? We'll have the stunning reliability of credit reporting services in every industry. But I digress...</ed.note>