Archive for the ‘SOA.Class.War’ Category


From SOA Consortium

The Practical Guide to SOA in Healthcare, an output of the Healthcare Services Specification Project (HSSP), is a collaborative work of the OMG Healthcare Task Force & Health Level 7 (HL7).
The goal of HSSP is to develop SOA specifications for health,
specifically defining healthcare business services to enable
interoperability between organizations across the health domain.

While
not a standard, the practical guide provides context and guidance for
healthcare IT organizations and professionals considering SOA. Using a
fictitious example, the practical guide presents an 8-step process to
establish a healthcare SOA, from enterprise architecture through
sustainment, and includes valuable lessons learned.

During his
talk, Rubin spoke of the current state of global healthcare, and
anticipated changes with the new U.S. administration and Health IT
programs. Walking through the practical guide, meeting attendees were
keenly interested in the healthcare function to service mapping and the
reference architecture. Rubin emphasized that the reference
architecture is a starting point for people to think about the problem,
and extend and amend for their own situations.

<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.

<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>

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

Agenda here.

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.

Agenda here.
<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>

"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

<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>

(more…)

Welcome To Conmergence

Conmergence Blog is visited by users of over 12,100 internet service providers; read by folks from 8,270 cities and 170 countries/territories. Twitter Grader says @ed_dodds is rated 98.5 out of 100 re: influence.