ThoughtWorks

About: ThoughtWorks is a based out in . It is known for research contribution in the topics: Agile software development & Extreme programming. The organization has 126 authors who have published 121 publications receiving 7310 citations.

Refactoring: Improving the Design of Existing Code

Abstract: Almost every expert in Object-Oriented Development stresses the importance of iterative development. As you proceed with the iterative development, you need to add function to the existing code base. If you are really lucky that code base is structured just right to support the new function while still preserving its design integrity. Of course most of the time we are not lucky, the code does not quite fit what we want to do. You could just add the function on top of the code base. But soon this leads to applying patch upon patch making your system more complex than it needs to be. This complexity leads to bugs, and cripples your productivity.

Microservices: The Journey So Far and Challenges Ahead

Abstract: Microservices are an architectural approach emerging out of service-oriented architecture, emphasizing self-management and lightweightness as the means to improve software agility, scalability, and autonomy. This article examines microservice evolution from the technological and architectural perspectives and discusses key challenges facing future microservice developments.

Design - Who needs an architect?

Abstract: W andering down our corridor a while ago, I saw my colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement: \" We shouldn't interview anyone who has 'architect' on his resume. \" At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizo-phrenia is the fact that, even by our industry's standards, \" architect \" and \" architecture \" are terribly overloaded words. For many, the term \" software architect \" fits perfectly with the smug, controlling image at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, there's a vital role for the technical leadership that an architect such as Dave plays. When I was fretting over the title for Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), everyone who reviewed it agreed that \" architecture \" belonged in the title. Yet we all felt uncomfortable defining the word. Because it was my book, I felt compelled to take a stab at it. My first move was to avoid fuzziness by just letting my cynicism hang right out. In a sense, I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important. (Yes, you can imagine a similar phenomenon for architect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Understanding came to me after reading a posting from Ralph Johnson on an Extreme Programming mailing list. It's so good I'll quote it all. A previous posting said: The RUP, working off the IEEE definition, defines architecture as \" the highest level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces. \" Johnson responded: I was a reviewer on the IEEE standard that used that, and I argued uselessly that this was clearly a completely bogus definition. There is no highest level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a …

Supporting the dynamic evolution of Web service protocols in service-oriented architectures

Abstract: In service-oriented architectures, everything is a service and everyone is a service provider. Web services (or simply services) are loosely coupled software components that are published, discovered, and invoked across the Web. As the use of Web service grows, in order to correctly interact with them, it is important to understand the business protocols that provide clients with the information on how to interact with services. In dynamic Web service environments, service providers need to constantly adapt their business protocols for reflecting the restrictions and requirements proposed by new applications, new business strategies, and new laws, or for fixing problems found in the protocol definition. However, the effective management of such a protocol evolution raises critical problems: one of the most critical issues is how to handle instances running under the old protocol when it has been changed. Simple solutions, such as aborting them or allowing them to continue to run according to the old protocol, can be considered, but they are inapplicable for many reasons (for example, the loss of work already done and the critical nature of work). In this article, we present a framework that supports service managers in managing the business protocol evolution by providing several features, such as a variety of protocol change impact analyses automatically determining which ongoing instances can be migrated to the new version of protocol, and data mining techniques inferring interaction patterns used for classifying ongoing instances migrateable to the new protocol. To support the protocol evolution process, we have also developed database-backed GUI tools on top of our existing system. The proposed approach and tools can help service managers in managing the evolution of ongoing instances when the business protocols of services with which they are interacting have changed.

Microservices in Practice, Part 1: Reality Check and Service Design

Abstract: Service-oriented architecture (SOA) and microservices insiders Mike Amundsen, James Lewis, and Nicolai Josuttis share their experiences and predictions with department editors Cesare Pautasso and Olaf Zimmermann.