Having a background in design, I've always felt a bit of a fake discussing web programming, however, the fact is that more and more designers are demonstrating that the whole left brain versus right brain, creativity versus logic idea is not as clear cut as is too often portrayed. While a good sense of aesthetics is important, it does not in itself directly equate to a well designed product. This is particularly true with web design, as a recent Web 2.0 Expo session entitled "The New Hybrid Designer" put it; "modern web design requires the coding savviness of a developer coupled with the aesthetics and user awareness of a designer". In this article I'd like to expand on an idea, put forward in that session, that choosing a decent platform or framework can provide an easier route into more productive development. The article is targeted at readers who already have experience working with PHP and are eager to improve their skills but don't necessarily have the background to know what they should be learning.

In this article, Michael Poulin elaborates on the differences between of governance and management and tries to explore the 'wonderland' of governance in a service-oriented environment.

In a new article, Eric Newcomer writes about the current status of distributed OSGi and explains the reasons for standardizing it in the first place.

Looking at recent articles and various BPM solutions, it would be easy to assume that BPEL is now the defacto standard to be used when implementing a workflow engine. From a technical perspective this may well be correct, however few people will claim that BPEL can be easily understood by the end-user, a.k.a the business analyst, who definitely prefers a graph based notation such as BPMN. This article will provide guidance in understanding the discrepancy between the technical point of view (pro-BPEL) and analyst's (pro-BPMN). Going further, even if most BPEL-based BPM solutions agree on the discrepancy (since they usually provide a BPMN to BPEL mapping) this article will explain why it is not currently the solution to BPM problems. A real-world example will be used to illustrate our arguments.

Every developer eventually encounters it at some stage in his or her career – the code that no one understands and that no one wants to touch in case it breaks. Sound familiar? But how did the software get that bad? Presumably no one set out to make it like that? The answer is that the software is suffering from Software Erosion – the constant decay of the internal structure of a software system that occurs in all phases of software development and maintenance.

Much has been written about DevOps, but most of it focuses on the Ops side of things. This article highlights the most important aspects for software architects and engineers. Itl covers core aspects that software architects should be aware of: DevOps, its motivation and its main practices, organizational aspects of introducing DevOps, and implications for software architecture.

This article looks at some of the myths and misconceptions around SOA and provide a crisp definition that bridges the technical and business views of SOA

This article presents a defense of the practice of architecture in software development. It defines the qualities of an effective architect and describes the skills required to succeed in this profession. The article examines widely held perceptions of architects and some of the mistakes that architects make which contribute to negative perceptions. Ultimately, the intent is to show the value good architects bring to a software development effort.

Service-oriented architecture (SOA) is taking a center stage in enterprise architecture. SOA enables parallel development by multiple disparate teams, each with its own delivery and maintenance schedule. In this article, I will examine service-versioning approaches, allowing service implementations to evolve without breaking existing consumers, leading to more loosely coupled SOA implementations. The basic idea of service versioning is fairly simple, but its implementation requires strict governance. I will discuss units of versioning; service changes, constituting a new version; service version life-cycle considerations; and version deployment/access approaches. The method-based service versioning proposed here allows one to minimize the impact of versioning and to reduce amount of deployed code. Semantic messaging for service-interface definitions makes service implementation more resilient to change.

Service-oriented architecture (SOA) is taking a center stage in enterprise architecture. SOA enables parallel development by multiple disparate teams, each with its own delivery and maintenance schedule. In this article, I will examine service-versioning approaches, allowing service implementations to evolve without breaking existing consumers, leading to more loosely coupled SOA implementations. The basic idea of service versioning is fairly simple, but its implementation requires strict governance. I will discuss units of versioning; service changes, constituting a new version; service version life-cycle considerations; and version deployment/access approaches. The method-based service versioning proposed here allows one to minimize the impact of versioning and to reduce amount of deployed code. Semantic messaging for service-interface definitions makes service implementation more resilient to change.