"Example isn't another way to teach; it's the only way" -- Albert Einstein
Patterns and pattern languages capture and formally codify good designs and best experience-based practices in a way that it is possible for others to reuse them. They successfully convey insight into common problems and their solutions. After all, common concepts, a vocabulary to describe them and a language to connect them together are the underpinnings for all disciplines and communities that practice them.
Christopher Alexander's research on buildings and town design is often considered the pioneering work on pattern-based thinking (see Resources). He coined the term "Pattern Language" to express his conviction that people's ability to design is as natural as their ability to use a language.
Patterns and pattern languages have been used by many disciplines, ranging from physiology and processes to project management and software engineering. Software design patterns became well accepted and used after the publication of the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (frequently referred to as the Gang of Four).
The software community is using patterns to resolve recurring problems encountered throughout the software lifecycle, ranging from software architecture and design to, more recently, software development processes and topologies. These patterns collectively capture the body of knowledge that represents our understanding of structures and mechanisms leading to well-architected software solutions.
A pattern is often defined as a "generalized, named problem-to-solution mapping." It captures a successful solution to a repeating problem in a particular context.
Often, software patterns are documented using a template similar to one depicted in Table 1, Pattern template.
Table 1. Pattern template
|Name:||A name used for identification|
|Problem:||A repeating problem that occurs in a domain|
|Solution:||Best practice solution to that problem|
|Consequences:||Advantages and disadvantages of the recommended solution|
|Examples||A few examples where the recommended solution has already been applied|
Software patterns provide a mechanism to capture knowledge and experience among architects and designers. They provide a common language and facilitate reuse of approaches that have been successful elsewhere and, thus, contribute towards the following aspects of a software project: reduced risk, increased quality and improved delivery time.
Antipatterns, on the other hand, document things that went wrong. Various surveys of hundreds of software development projects undeniably illustrate that things can -- and often do -- go wrong with software development. Studies show that five out of six projects fail: delivered far over the expected budget, significantly late, or are canceled. This suggests that it might be (at least) as worthwhile to examine causes for frequent failures as the rare instances of success (Noted author of Bitter Java, Bruce Tate, demonstrated in his developerWorks article how and why antipatterns are a necessary and complementary companion to design patterns (see the Resources section for more information).
These repeated failed software development projects or "negative solutions" should be mined to harvest useful knowledge of "what went wrong and why." Obviously, just categorizing the causes of failure is not as useful as also examining how to avoid them and how to recover when one is encountered. When codified, this collective knowledge makes a valuable extension to software patterns and classified as antipatterns.
Antipattern is a frequently used, but largely ineffective solution to a problem. The term was originally used to refer to a design pattern gone wrong. Similarly to patterns, use of antipatterns has extended to all software development phases and beyond, to other domains. Antipatterns document commonly recurring solutions that have counterproductive effects. They typically capture refactored solution descriptions, showing how to change the antipattern into a healthier solution. Antipatterns are usually described in a template that identifies symptoms, consequences, root causes, and potential solutions. Although antipatterns are not as widely studied and written about as patterns, some of them, which have colorful monikers such as analysis-paralysis, blob, spaghetti code, and stovepipe systems, are readily recognizable by the software community. Table 2 provides an overview of some of these examples sourced from Brown et. al.'s antipatterns book (see the Resources section for more information).
Table 2. Examples of known antipatterns
|Design||Blob||A large class with too many attributes and is the "heart" of the system|
|Design||Poltergeists||Unnecessary classes and too much abstraction|
|Structure||Spaghetti code||Program code that has no structure (lots of goto statements)|
|Structure||Stovepipe systems||Applications are unique and isolated|
|Technology||Wolf ticket||A technology that claims openness, but has no conformance standard test|
|Technology||Continuous obsolescence||The attempt to use the latest release|
|Reuse||Cut-and-paste||Software errors are duplicated|
|Reuse||Golden hammer||Forcing everything to fit a selected tool|
Why are antipatterns important? Antipatterns are tools to prevent problems by helping to identify a problem before it becomes a problem, and by providing knowledge on how to prevent that from happening. Formal codification of failure causes allows us to intelligibly understand them. Once problems occur, antipatterns can help by explaining how to recover from them.
To summarize, antipatterns have the following elements:
- Documentation of what does not work
- A common vocabulary
- Detailed remedy
- Awareness of situation and alternative solutions
- Today's hot solution that can be tomorrow's antipattern
Figure 1 expresses the difference between patterns and antipatterns. A pattern starts with a problem that you are trying to solve and documents a repeatable successful solution to it. The solution generates some benefits, consequences and possible problems. An antipattern demonstrates a frequently used solution to a problem that has counterproductive effect. It describes the causes that led to it and also shows how to prevent or correct the solution.
Figure 1. Patterns versus antipatterns (Source: Brown et. al., "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis")
In the last five years, much has been written about service-orientation, SOA and more recently, service-oriented everything. But what do we mean by services and service orientation?
There are many different definitions -- and the definitions have changed reflecting maturity of the industry and SOA practices. We provide here some base-line definitions to be used in this article. The definitions are reflected in Figure 2.
Figure 2. Definitions of SOA
- First of all, what is a service? A service is a repeatable logical manifestation of a business task. It is important to stress that we're talking about a part of a business process here -- not about software or IT.
When realized through technology, the term service applies to a software resource (discoverable) with an externalized specification. This service specification is available for searching, binding, and invocation by a service consumer. The service provider realizes the service specification implementation and also delivers the quality of service requirements to the service consumer. Services shall be governed by declarative policies and thus support a dynamically re-configurable architectural style.
- Second, what is service orientation? Building on our definition of a service, service orientation is a way of integrating a business as a group of linked services. We are still not talking about technology; we are talking about a new way of looking at business and how it operates.
- What is SOA? SOA is an architectural style that supports the service orientation. SOA is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed in a value-net, enterprise, or line of business to fulfill business needs.
- And finally, what is a composite application? It's a set of integrated services. Composite applications are the actual running services that have been assembled and strung together to support what a business does. The primary structuring element for SOA applications is a service as opposed to subsystems, systems, or components.
SOA antipatterns were identified using the following approach:
- Surveyed literature for published antipatterns
- Documented antipatterns discovered by the authors on engagements in client meetings
- Surveyed SOA CoE and CoP members for antipatterns identified from their experiences
- Used recognized antipatterns template/language
- Antipatterns included in this presentation have been agreed upon by the three authors
The antipatterns are described using the following template / language:
A succinct name to convey the essence of the antipattern
- Problem / Bad solution
The commonly occurring mistake or bad solution that relates to the antipattern
The indications or signs of the problem
The results of applying this antipattern
- Root cause
This provides the context for the antipattern, that is, where a pattern was applied incorrectly and resulting in a problem or failed solution
- Suggested solution(s)
Refactored solution that solves the problem and ensures more benefits
The identified antipatterns are classified into three categories:
- SOA Adoption antipatterns: These are antipatterns that hinder or delay SOA adoption by customers and businesses. Antipatterns discussed in this category are:
- A1. Technology Bandwagon
- A2. So, What's New?
- A3. The Big Bang
- Service identification & design antipatterns: These are antipatterns encountered while practitioners work on identifying and designing services as part of a SOA initiative. Antipatterns discussed in this category are:
- I1. Web service = SOA
- I2. The Silo Approach
- I3. Misbehaving Registries
- Service realization antipatterns: These antipatterns capture worst practices for realizing services. Many of these antipatterns are focused on web services implementation; the most common realization of SOA. In this paper we identified a partial list of SOA realization antipatterns that are not focused on web services since such antipatterns are better discussed in a forum devoted to web services. Antipatterns discussed in this category are:
- R1. Chatty Services
- R2. Point-to-point Services
- R3. Component-less Services
As SOA matures and more engagements are conducted it is expected that more antipatterns will be identified.
Table 3. List of antipatterns
|Category - ID||Antipattern||Description|
|Adoption - A1||Technology Bandwagon||A noted common trend where corporations decide to jump on the new technology bandwagon without careful consideration whether this technology have any contribution to the business.|
|Adoption - A2||So, What's New?||Lack of understanding of the differences between SOA and previous computing paradigms drives skeptical to claim that SOA is just a name for same old techniques. The result is opposition to the adoption of SOA even if such adoption benefits the business.|
|Adoption - A3||The Big Bang||This antipattern is also known as "Bite more than you can chew." It is observed when SOA is viewed as a panacea, leading to a push to change all the enterprise systems and architecture at once. Such a big bang adoption could result in failures that are then unjustly blamed on SOA.|
|Identification & Design - I1||Web service = SOA||When architects equate SOA with web services they run the risk of replacing existing APIs with web services without proper architecture. This will result in identifying many services that are not business aligned.|
|Identification & Design - I2||The Silo Approach||In this antipattern, services are identified based on isolated applications, thus same services are identified by different groups with different names. As a result, no common services or service sharing are realized.|
|Identification & Design - I3||Misbehaving Registries||Duplicate service registries and overlapping, unclear ownerships result in governance nightmare and runtime confusion, potential bad performance, and unplanned costs due to duplication.|
|Realization - R1||Chatty Services||This antipattern describes a common mistake developers usually make when they realize a service by implementing a number of Web Services where each communicates a tiny piece of data. This will result in the implementation of a large number of services leading to degradation in performance and costly development.|
|Realization - R2||Point-to-point Services||Using XML or SOAP over HTTP between applications replacing middleware by point to point web services results in the emergence of point-to-point integration as the defacto integration pattern.|
|Realization - R3||Component-less Services||By jumping into development and implementation of web services without having a clear association with owning components results in unstructured and undisciplined architecture (non strict layering). This leads to inflexibility behind the service interface and in preserving the legacy limitations of existing applications and packages.|
These are antipatterns that hinder or delay SOA adoption by customers and businesses.
We observed that many corporations embark on a SOA effort leading from an IT perspective instead of a Business one. Implementations might be technically feasible and sometimes successful, but the impact on the business may not be realized since it was never considered in the first place.
This antipattern is mostly observed in large corporations with well established IT departments that employ highly technical staff supported by strong and influential technically oriented leadership.
A common symptom of this antipattern is the inability of the sponsors to articulate the value proposition of SOA adoption. Also, lack of business alignment with the projects targeted for SOA implementation could be another symptom.
As a result of this antipattern, the cost of IT rises without realizing any return on investment (ROI). In addition, the corporation may lose the opportunity to infuse flexibility into the IT portfolio.
- Root Cause
In most cases, the root cause of this antipattern stems from the pressure on a corporation to match or keep up with announcements from competitors who may claim leadership through the adoption of this technology. As a result, the corporation might find it easier to dive into a technology-based effort to adopt SOA without taking the time and the effort to align it with the business needs.
The best approach to deal with this antipattern is to establish hype-free SOA value propositions which can be accomplished by identifying and describing how SOA addresses client-specific pain points or business challenges. This approach can be complemented by the development of a roadmap for proper introduction of technology in support of the business.
- Solution example: Develop a SOA platform based on hype-free SOA value propositions
A global car rental company understood the value propositions of a SOA solution that would support its key business drivers:
- Provide a flexible business model to increase speed and flexibility in delivering new business services
- Drive down costs by streamlining processes to reduce operating costs
- Reduce cycle time and costs for external business processes by providing first-to-market innovative services for its customers
- Integrate across the enterprise by enabling easy and flexible integration to support multiple delivery channels
This antipattern describes a situation where skeptics in a corporation claim that SOA is just a name for same old techniques and that SOA doesn't offer any thing new that they haven't been doing already. On the surface, that may appear to be so, but the emergence of web services and XML, amongst other related standards is a major differentiator of what was done compared to what can be done with the appropriate implementation of SOA.
This antipattern is mostly adopted by IT personnel who are comfortable with the technology they have been using for an extended period of time and are reluctant to introduce or consider changes. It also appears in situations where IT departments have gone through a painful technology transformation or that the new technology didn't live up to its hype.
The most obvious symptom is the strong opposition of some technical managers in a corporation to consider SOA as a serious approach to address legitimate business problems. The opposition could be in the form of strong and explicit arguments against the adoption of SOA, or it could be implicit and passive by ignoring SOA altogether while discussing approaches to solutions for business problems.
This antipattern most likely will foster lack of support for SOA that will result in missed opportunities to realize the SOA value propositions that will support business pain points.
- Root Cause
Though SOA builds on the same principles introduced and supported by other computing paradigms (for example, Object-Oriented and Component Based Development), many experienced IT teams lack real understanding of the differences between SOA and these other computing paradigms. This lack of understanding is one of the basic root causes of this antipattern. Another root cause is a direct consequence of IT teams having had bad experiences in implementing too many "Paradigm Shifts" and as such they are not willing to try a new one.
One way to deal with this antipattern is to emphasize how SOA is different from earlier solutions. For example, the differences between an APIs and Services should be explored, and dependency on Open Standards and their differentiating attributes should be explained. Another major differentiator is the emergence of the Enterprise Service Bus (ESB) as an essential component of SOA. The facilities provided by an ESB such as Transport Services, Mediation Services, and Event Services, are examples of new capabilities made available by adopting SOA. However, the most effective solution is to provide successful examples that will highlight the differences and demonstrate the success and feasibility of implementing a SOA solution.
- Solution Example: SOA Education
Educate both business and IT on what SOA is, its value propositions and the benefits it provides to deliver IT flexibility that is required to support business goals. Provide an understanding of the importance of the web services and XML standards and emerging standards in the implementation of SOA that distinguishes it from past paradigm shifts.
This antipattern can be thought of as the extreme opposite of the "So, What's New" antipattern. Here the problem is that the advocate view SOA as a panacea, leading to a push to change all the enterprise systems and architecture at once.
This antipattern shares the same context as the Technology Bandwagon antipattern. In particular those enterprises where major stake holders are very technically oriented and are more influential than their business counterparts, you can expect them to try to "bite more than they can chew" regardless of the effect on the business.
Overwhelming concerns from business units about the proposed changes to adopt SOA is a clear indication that this antipattern has been exercised.
A result of applying this antipattern is serious failure to deliver on the promised benefits of SOA, which may lead to a return to existing architecture thus delaying or even eliminating any potential benefit from SOA. Another consequence of exercising this antipattern is to blame any failure to deliver on SOA rather than finding the root cause of the problem.
- Root cause
Zealous technologists in any enterprise can be the root cause of such an antipattern, particularly if these technologists are in a position to make IT decisions override business concerns.
To eliminate this antipattern, one solution is to develop a business supported roadmap to move towards SOA incrementally. Instead of trying to solve all the enterprise problems through sweeping changes using SOA, it would be better to adopt an incremental approach by building a business case for a pilot first, then when the pilot is successful, use the roadmap to select the next target business area for which SOA would be beneficial. It will also be helpful if education on SOA entry points is made available to those in the organization that are responsible for the push to SOA.
- Solution example: Develop a roadmap to implement SOA
Given its business strategy, a major bank determined that a SOA solution was the appropriate architectural direction that would enable it to meet its business goals. It first conducted an assessment of its maturity level in terms of service integration. Then a roadmap was developed to enable the bank to incrementally migrate to a SOA environment so as to minimize risks while continuing to provide the necessary business functionality. A pilot project was selected to validate the SOA architectural style and to work out any technology and organizational issues while moving to this SOA paradigm.
These are antipatterns encountered while practitioners work on identifying and designing services as part of a SOA initiative.
To many, SOA is just another name for web services. Though implementing web services is a legitimate entry point towards SOA adoption, enterprises should not equate web services with SOA.
Most of today's production web services systems are not SOAs. They're simple remote procedure calls or point-to-point messaging through SOAP or well structured integration architectures. Organizations find it easier to claim a move to SOA by only implementing web services.
Replacing existing APIs with web services without proper architecture as well as implementation of services that are not business aligned are obvious symptoms of this antipattern.
Proliferation of web services is a direct consequence of the application of this antipattern. This is a result of implementing any interface as a web service regardless of whether these services are part of a SOA value proposition or not. Also, it is likely that the resulting systems will not have interfaces that reflect the requirements of the service requestor.
- Root cause
Root causes for this antipattern fall in two categories. The first is haste, where the intent is to take short-cuts and do this SOA stuff quickly and cheaply. The second is ignorance of the difference between SOA and Web Services and lack of understanding the need for good service modeling techniques.
An approach toward addressing this antipattern is to develop a viable SOA transition plan which requires organizations to define their SOA value proposition. Achieving the SOA value propositions requires both SOA and web services. This will require education on SOA versus web services as well as applying good service modeling method such as SOMA (Service-Oriented Modeling and Architecture).
- Solution example: Apply service modeling to identify coarse-grained services and leverage web services as the implementation technology for a SOA solution
Adopt and use a good service modeling technique to determine appropriate coarse-grained services for a business solution and leverage web services to implement a SOA solution. The right level of service granularity would help minimize the proliferation of services that are too fine-grained. Achieving the value propositions of SOA requires both SOA and web services.
The problem presented by this antipattern is a result of the way services are identified. When services are identified based on isolated applications rather than focusing on the enterprise strategy, the benefits expected from SOA implementation never materialize.
Enterprises that are organized based on a functional model with towers that are working in isolation are prime candidates for this antipattern. The autonomy each functional tower enjoys lead to the working in a silo approach.
Observing that same services are identified by different groups with different names is a symptom of this antipattern. Failure to identify common services or lack of realizing service sharing is also a clear indication that this antipattern has being applied.
Since services are identified and implemented multiple times as a result of the silo approach, costly development of unnecessary or duplicate services negates the benefits promised from adopting SOA. Furthermore, reuse between stake-holders of different applications diminishes or is completely eliminated as a result of this antipattern.
- Root cause
In most cases, organizational boundaries and constraints are the root cause of this antipattern. In some enterprises, the lack of a disciplined approach to "service exposure decisions" is attributed as the root cause.
The solution to this antipattern is to establish a governance framework that will ensure cross tower service identification and communications. Also, a focused effort on identifying common services should be initiated and enforced. This can be accomplished using a good service modeling method such as SOMA.
- Solution example: Identifying common services
Like most corporations, a major bank was organized by business towers which provided similar business functionality to different types of bank clients. SOMA was applied to develop a service model to facilitate and understand opportunities of reuse across the business towers. At a high level, about 90 percent of the business services that were needed to support business functionality were found to be similar and were potential areas of reuse.
UDDI adoption without an agreed upon SOA governance model leads to process inefficiencies as well as design inefficiency. In particular duplicate registries can cause inefficiencies resulting in bad performance as well as creating security and compliance holes.
Enterprises that do not have an agreement on the registry governance but attempt to establish UDDI usage will often encounter this antipattern.
Given that UDDI is a standard and not a product, its improper use can lead to the establishment of duplicate service registries and overlapping, unclear ownerships. This will manifest itself in the form of incorrect, misleading service interface information particularly during the discovery of composite service scenarios within a shared services model. Despite individual service interfaces having the correct description in the registry, duplicate entries will result in the discovery of incorrect whole services. Furthermore, lack of a governance model could result in services that are registered along various stages of life cycle process but become abandoned when there is no one to one ownership transfer. For example: a developer may add three services in to the internal UDDI. Then the service administrators may pick only two of them to be moved to the production UDDI. This results in orphaned services. A similar situation may arise with the service components.
Duplicate registries will create governance nightmare and runtime confusion in trying to identify which service in which registry that is causing failure to meet SLAs. Additionally, potential bad performance and security and compliance holes could result from such duplication. Unplanned costs due to duplication are also another consequence of this antipattern.
- Root cause
Lack of design-time coherence (SOA governance model) is the leading cause of this antipattern. In particular, unclear service registry ownership and lack of establishing and enforcing enterprise level SOA reference architecture are at the core of the problem.
To avoid this antipattern, a corporation must establish a SOA governance model that defines and adopts service registry best practices, ownership, and communications across related teams. This would eliminate duplicate and incorrect service interface information and minimize the consequence of having orphaned services. Runtime confusion would also be eliminated since there is only one source of service descriptions which include the associated SLAs and policies. Establishing and enforcing compliance with a SOA enterprise level reference architecture should be the first step towards the institutionalization of a SOA governance model.
These antipatterns capture worst practices for realizing services.
This antipattern describes situations where developers realize a service by implementing a number of web services where each communicates a tiny piece of data. Another flavor of the same antipattern is when the implementation of a service ends up in a chatty dialog communicating tiny pieces of information rather than composing the data in a comprehensive document-like form.
In organizations where developers are eager to start implementing without proper modeling, they end up being victims of this antipattern. In some situations, where developers are asked to start replacing APIs with web services and without proper understanding of how to best benefit from SOA, it usually leads to this antipattern.
The need to implement a large number of too finely grained services is an indication that this antipattern is being applied.
Degradation in performance and costly development are the major consequences of this antipattern. Additionally, consumers have to expend extra effort to aggregate these too finely grained services to realize any benefit as well as have the knowledge of how to use these services together.
- Root cause
As a result of not knowing any better, the approach many developers take is to mimic API implementation in the form of web services. This is very similar to the situation we encountered at the beginning of the object-oriented paradigm shift, where developers used object-oriented languages to develop procedural programs. Also, excitement to dive into this new technology could cause everything to become a web service with no benefit and excessive cost.
To avoid this antipattern, a focused effort should be on refactoring the design to combine individual pieces of data in one document thus eliminating the chatty services. Education on differences between API and service with focus on appropriate service granularity would also help. However, the most effective approach to avoid this antipattern is to define services that map back to business goals. This can be accomplished by adopting and using a good service modeling technique to determine appropriate coarse-grained services for a business solution. This minimizes the chatty behavior of services since it has been identified at the correct level of granularity appropriate in a SOA. Applying a Service Litmus Test (SLT) would also help determine the right level of services to expose. An example of a SLT is to consider whether a service provides a required unit of business functionality that supports business processes and goals.
The basic problem is the attempt of developers to replace a middleware solution with point to point web services as an integration approach regardless of the usage context.
This pattern is observed in organizations where there is lack of long term systems integration vision with emphasis on short term results.
An indication that this antipattern is being exercised is the use of XML or SOAP over HTTP between internal applications.
As a result of using this antipattern, the point-to-point integration solution emerges as the defacto integration pattern for the enterprise. This will negate any potential for achieving the full advantages of proper SOA implementation.
- Root cause
A lack of consideration for the long-term maintenance and evolution of the overall system, potentially as a result of focusing on short term solutions, is the principle root cause of this antipattern. In some cases, excitement about using services everywhere could also lead to the proliferation of such point to point services approach.
To avoid the consequences of adopting this antipattern, the use of an intelligent connector such as a Service Bus should be seriously considered as an integration approach. A Service Bus enables applications to work together simply and efficiently to support business needs while maintaining loose coupling between collaborating systems and applications.
- Known exceptions
There are some known exceptions for which the antipattern solution is acceptable. For example, a quick, short-lived integration scenario is required to solve immediate business problems and one case where point to point services could be used. However, there is a tendency for these solutions to stay in production for a long time. Thus applying this antipattern should be carefully monitored and controls should be put in place to prevent its long term adoption.
Good practices for service modeling promote associating identified services with components that own them. The problem presented by this antipattern is the tendency of developers to jump into developing and implementing web services without having a clear association with owning components.
This antipattern appears in environments where architecture patterns are not applied or considered, for example, the layering architecture pattern. This lack of architectural discipline provides an environment that fosters the application of this antipattern.
Examination of services' implementation will reveal that direct reach of any part of the system is allowed without adhering to any architectural structure. In these cases, web services are developed without any regard to the concepts of layering and separation of concerns.
The most notable consequence is the inflexibility beyond the service interface since modular design, information hiding and logical structuring principles are all violated. This will lead to preservation of legacy limitations of existing applications and packages, which may prevent potential reengineering in the future.
- Root cause
As with any other situation where best practices are violated, the root cause of this antipattern is the lack of good design.
The true potential of components and SOA will only be realized when you have both of them. Coherent service interfaces supported by flexible component-based applications is the solution. This will require developers to continue to leverage J2EE and general EAD best practices and layering patterns as a mean to overcome the shortfalls of this antipattern.
- Solution example: Understand the value of components with SOA
Services are optimally realized with components. Without components, there is inflexibility behind the service interfaces, with potential concerns about scalability and portability of implementation. Existing applications and packages preserve their legacy limitations and this would minimize the ability to provide the flexibility needed to support changing business needs. Components provide the scalability and flexibility to support the service interfaces with its loose coupling and reuse features.
In this article, we reviewed some of the SOA antipatterns gleaned from observations and SOA projects that affects the adoption, identification & design, and realization of SOA.
The authors would like to thank the following colleagues for their contributions to this paper:
- JeanPierre Paillet
- Kerrie Holley
- Kyle Brown
- Mike Ellis
- Olaf Zimmermann
- Prathap Gangula
- Rick Robinson
- Rolando Franco
- Sri Ramanathan
- For more information on antipatterns, check out the following books:
- The Timeless Way of Building, by C. Alexander
- Notes on the synthesis of form, by C. Alexander
- The Oregon Experiment, by C. Alexander
- A Pattern Language: Towns, Buildings, Constructions, by C. Alexander
- Antipatterns: Refactoring Software, Architecture, and Projects in Crisis, by W. Brown, R. Malveau, H. McCormick III, and T. Mowbray
- J2EE Antipatterns, by B. Dudney, S. Asbury, J. Krozak, K.Wittkopf
- Web Services Architecture & Best Practices (IBM WebSphere Developer Technical Journal, Oct 2003) : Book excerpt that covers some of the architectural challenges posed by web services, examines how to use (and not to use) web services, and describes some best practices in applying web services for solving tough architectural problems.
" A taste of "Bitter Java"" (developerWorks, March 2002) : How antipatterns can improve your programming.
- SOA and web services -- hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop web services applications.
- Architecture: Build for the future -- visit the new Architecture area on developerWorks and get the resources you need to advance your skills in the architecture arena.
- developerWorks blogs: Get involved in the developerWorks community.
Luba Cherbakov, IBM Distinguished Engineer and member of the IBM Academy of Technology, is a key technical leader in IBM Global Services. She is a recognized expert in enterprise architecture design and development of complex distributed applications using service-oriented and component-based methods. Luba is a key contributor to architecture and delivery of many complex and first-of-a-kind IBM Global Services solutions across a wide variety of customer industries. Luba led development of the IBM Service-Oriented Modeling and Architecture (SOMA) method. She is an author and an advocate of the reference architecture assets, the Architecture Description Standard, and the grid computing offerings. Luba is a recipient of the IBM Outstanding Technical Achievement Award. A member of IEEE Computer Society, the Society of Women Engineers and ACM, Luba holds master's degree in Computer Science from the George Washington University, with major in Software and Systems, and minor in Artificial Intelligence and Simulation.
Dr. Mamdouh Ibrahim is a Senior Certified Executive IT Architect with the Enterprise Architecture & Technology Center of Excellence, and a member of the SOA & Web Services Center of Excellence extended team. He has over 30 years of experience in both industry and academia in the areas of Enterprise Architecture, Service Oriented Architecture, Distributed Computing, and Wireless technologies. He is a member of the IBM IT Architect Certification Board and an author and instructor of the IBM Architectural Thinking course. Dr. Ibrahim holds a Ph.D. in Computer Science; Master degrees in Computer Science, Solid State Science, and Mathematics; and Bachelor degrees in Electrical Engineering and Mathematics. He is an adjunct faculty at Central Michigan University. He served as the OOPSLA 2002 General Chair and currently serving as the OOPSLA Steering Committee Chair till 2008. He is a member of ACM, IEEE Computer Society and AAAI.
Jenny Ang is an Executive IT Architect with the SOA and web services and the Enterprise Architecture & Technology Center of Excellences. She has extensive experience in architecture and methodology and is currently focused on service-oriented architecture, web services, component-based development and web-based development projects. She is a co-author of the IBM redbook "Patterns: Service-Oriented Architecture and Web Services".