Há tempos não voltava ao assunto, apesar das promessas. O "pacotinho" do título não tem nada a ver com algum produto mágico, please! (SOA não depende de "pacotinhos" e afins.)



É que vou surrupiar os "melhores momentos" de dois artigos novos sobre o tema. O primeiro é do Peter Coffee (whataname!), do eWeek:

* SOA construction is increasingly being driven by financial rather than technical imperatives, resulting in broader and more vigorous management support for the direct and indirect costs of such a transformation.
- Finalmente! Um tipo de projeto de TI que não é guiado por 'imperativos técnicos'. Mas que também não é uma 'tesoura de custos' por si só.

* Web services adopters are less inclined to walk around the technology seeking excuses -- such as gaps in multivendor standards -- to postpone trying it out. They're more likely to see the standards glass as nine-tenths full rather than one-tenth empty, and to build what they can with what they have today.
- Para desespero de todos que querem vender 'pacotinhos'.

* The advent of a genuine services platform in an organization paves the way for a service-based organization that has the leverage to break down silos of data and code and start building more efficient and strategic systems.
- Mais promessa que realidade ainda. Ainda...


Mudando um pouco de foco: o ZapThink apresenta artigo com os 4 pilares do desenvolvimento SOA:

Pillar #1: Iterative development -- we're representing each sphere of development with a pair of arrows to indicate the fundamentally iterative nature of SO development. Business analysts must work iteratively with business users, both to satisfy the original requirements as well as to maintain agility as those requirements change. Likewise, component developers must continually iterate their code to satisfy ongoing changes to the Service contracts.
- Um tanto óbvio, não? Ou será que alguém ainda acredita que pode desenvolver 'sistemas ágeis' com métodos-queda-d'água-jurássicos?

Pillar #2: User involvement -- unlike the waterfall model, where users specify requirements at the beginning of a project only, business users continually drive SO development. The meta-requirement is for a system that responds well to change, and as a result, the "requirements definition phase" of any SO project is actually a set of ongoing activities.
- Engenharia de requerimentos é uma 'fase' (sic) sem fim. E não apenas em projetos SOA. (Ah, projetos terminam? E seus produtos?)

Pillar #3: Contract-first development -- Business analysts work with users to distill requirements into contracts that then act as the marching orders for component developers. Such metadata both represents the requirements as well as the test plans that analysts can execute to guarantee that Services meet their requirements. In other words, contract-first development is an example of test-first development, and both approaches are examples of metadata-driven application development.
- Prática excepcional que segue ignorada na maioria dos projetos e 'processos'.

Pillar #4: Refactoring -- The Services layer of abstraction affords IT the luxury of a curtain that hides the inner workings of the technology from the business. Rather than an excuse to maintain a poor infrastructure, this abstraction layer actually gives IT more leeway to make continual improvements to the technology. Refactoring is thus the underpinning of reuse, as IT may now work to streamline technology across platforms to meet the needs of the business.
- Será que realmente utilizaremos tal 'cortina' bem? Nossa 'cultura atual' é mais de 'varrer para trás da cortina' do que de 'melhoria contínua'. De qq forma, taí o 4o e último pilar.