Thinking SOA

A Service-Oriented Architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA.
CORBA ? ORBS ...this is SOA until 1967.


CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architecture.

SOA not new technologies, SOA is re-engineering the CORBA and similar concepts...

Software architecture is a coherent

Software architecture is a coherent set of abstract patterns, or principles, guiding the design of each aspect of a large software system.

Software architecture underlies the practice of building computer software. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans, so too, a software architect or systems architect sets out the software architecture as a basis for actual system design specifications, as per the requirements of the client.

Software architecture is like an architecture of a building in that it has to do with the purpose, themes, materials, and concept of a structure. A software architect employs extensive knowledge of software theory and appropriate experience to conduct and manage the high-level design of a software product. The software architect develops concepts and plans for software modularity, module interaction methods, user interface dialog style, interface methods with external systems, innovative design features, and high-level business object operations, logic, and flow.

A software architect consults with clients on conceptual issues, managers on broad design issues, software engineers on innovative structural features, and computer programmers on implementation techniques, appearance, and style.

Software architecture is a sketchy map of the system. Software architecture describes the coarse grain components (usually describes the computation) of the system. The connectors between these components describe the communication, which are explicit and pictured in a relatively detailed way. In the implementation phase, the coarse components are refined into "actual components", e.g., classes and objects. In the object-oriented field, the connectors are usually implemented as interfaces.


What is Software Architecture? Some definitions make me feel a little confused about structure and architecture. According to Bass’s book, one software architecture can have many structures at the same time. So what is the difference between software structure and software architecture? English is not my first language, so I have to borrow a hand from dictionaries. In Merriam Webster, structure means "the arrangement of particles or parts in a substance or body" (I just picked one meaning which I think is more proper than the others to my topic) while architecture is "art or science of building; specifically the art or practice of designing and building structures" according to MW. Architecture seems having much more things than structure. So I believe that software architecture contains structure or structures. Many people think structure and view can be used interchangeably. However, that depends on how you understand the word "structure". I would rather make it simpler to think it as only a module structure, which contains components and connectors,, which is also the elements mentioned in Perry and Wolf’s paper. Since software architecture is the art and science of building software structure, it must have much more plentiful contents, such as rationale (which is related to requirements and implementation), abstraction, architectural style, overall structure, constraints, multiple views, multiple models, and so on, it even includes representation and evaluation. I have to admit that I am a total beginner to this discipline, so please forgive me if some idea seems quite immature to you. However, I just want to make sure if I really understand what I am doing now. Finally, I agree, in practice, as Bass said in his book, the lack of an engraved definition will not prevent us from making good use of the concept 


Source :
Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice. Addison-Wesley, 1998.
Dewayne Perry, Alexander L. Wolf. Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes, pp. 40-52, October 1992.

DNA of Software Architect ...

Software Architects must have excellent communications and base technical software skills.
Communications skills are the skills that I work on the most because they are the most critical for an architect. Don’t get me wrong: technical skills are an absolute necessity, but without top communications skills, it’s going to be difficult to get your vision into the heads of others. Many of the disciplines, attitudes, and ideas that I discuss in my IT operations article also apply to solutions architecture. The highest responsibility of an architect is communicating the solution to the business leaders, technical leaders, and any other interested parties in a language that they understand. Architects need to have a mastery of three languages: business language for communicating with the business people, industry language for communicating in the vernacular of the business, and technical language for communicating to the technical leadership and the developers. I personally have a dual degree having majored in business (marketing) and minored in engineering. I actually started out in engineering and then started taking business classes in my junior year. At a job fair job fair I kept hearing that I should take some business classes because I would be out working with business people and would need to understand their world. Thinking back, my team won an engineering competition not because of the technical merit of the solution, but because we had given the business case for the solution to a panel of judges who happened to be all business people. We spoke in a language that they could understand. We need to speak in a language that an audience can understand. It is often the case that the audience will not tell you when they do not understand you, and a confused mind will always say no. So be sure to understand your audience, and then be sure to speak their language. I have worked in many different industry sectors, all with their own specific domain languages. As a result I picked up a habit early on in my career that has allowed me to quickly learn each domain. In most business lobbies, trade magazines for that industry are displayed. I would read these magazines as I would wait to meet with the client. I would also take the free subscription cards for the journals and send them in to get my own copies of the periodicals. Granted this was before the Internet, which has made industry specific research much easier. The point is that you need to become familiar with the domain in which you will be developing a solution. And whilewe are on the topic, I believe that there is a tremendous benefit to having experience in multiple industries and domains.


This allows you to be like a bumble bee and cross-pollinate the best ideas across industries. I have also found that the DNA of most architects has a hunger for knowledge in a broad range of subject areas. Architects are interested in knowing about things and understanding how things work. Architects can then synthesize this knowledge into creating solutions. 

It is assumed that architects know the technical language. Yet this is not always the case as not all architects come from the technical ranks. And even if an architect comes from the technical ranks, their vocabulary and experience may still be narrow enough to hinder communications to all parties. I believe that an architect needs to understand several development methodologies and development environments, and also understand infrastructure, security, databases, business integration, and operations and support. Blindness in any of these areas can cause problems, however such limitations can be overcome with a team of architects and or a good network of peers. 

Source : ITABOK - http://www.iasahome.org/web/home/skillset

Uma boa opção para definir e customizar processo de engenharia de software

Se queremos produzir com apoio de uma ferramenta um processo de engenharia de software customizado no que a empresa necessita, pode-se atualmente encontrar com boa qualidade.

O Eclipse Process Framework (EPF) visa produzir um software com características próprias, fornecendo ferramentas e conteúdo que pode ser usado como base para uma grande variedade de processos de TI a fim de resolver necessidades. O EPF ajuda na autoria de métodos, ferramentas, processos, gestão de configuração de bibliotecas de métodos para processo e publicação de processos. O Framework conta com exemplos de processos prontos para serem adaptados, reutilizados a processos de desenvolvimento de software e ferramentas que são suportadas por vários tipos de projetos e formas de desenvolvimento. Ao usar EPF Composer pode-se criar o seu próprio processo de desenvolvimento de software e estruturá-lo em sentido específico, usando um esquema predefinido, aderente ao processo a ser registrado. Este esquema é uma evolução da Software Process Engineering Meta-Model (SPEM 1.1) de especificação referida, como o da Arquitetura do método unificado (UAM - Unified Architecture Method). Grandes partes da UAM foi recentemente adaptada para a revisão da SPEM e o EPF Composer irá apoiar plenamente o SPEM 2.0 em futuro próximo. A UAM e a SPEM são projetos de apoio à organização, com grande quantidade de descrições de métodos e processos de desenvolvimento.

Os projetos individuais de diversas organizações de desenvolvimento de software podem facilmente transferir e implantar os processos capturados no EPF. Eles podem personalizar processos existentes através da mistura de correspondência de conteúdo de vários processos, por remoção, adição ou personalização de conteúdo através da aplicação de conteúdos fornecidos por plug-ins. Os processos resultantes podem facilmente ser implantados, e continuamente evoluir, acomodando as lições aprendidas à medida que o projeto avança.



Definição do Processo com o auxilio do EPF Composer


O processo foi definido com a intenção de ser mais leve possível, mantendo entretanto a formalidade necessária para o desenvolvimento flexível, ágil e estável.

Como visto anteriormente a grande particularidade do EPF Composer é a categorização dos elementos padronizados no SPEM, em dois conceitos principais. São eles: Method Content e Process.

O Method Content descreve o que deve ser produzido (WorkProduct), as competências necessárias exigidas (roles), e as instruções passo-a-passo (steps) explicando como os objetivos serão atingidos. Process descrevem o desenvolvimento do ciclo de vida, relacionando os elementos dos Method Contents em seqüências semi-ordenadas que são personalizadas para determinados tipos de projetos.

Ao definir o processo no EPF foi criado primeiramente o plug-in, que poderia ser denominado hipoteticamente como PDS ou Processo de Aquisição de Software. Posteriormente foi criado a estrutura de pacotes dentro do Method Content que, nesse


caso, foram as etapas do processo definido levando em consideração o ciclo de vida do projeto, por exemplo: requisitos funcionais e não-funcionais, projeto, desenvolvimento, etc.. Cada pacote é expresso usando WorkProduct (artefato), role (papel), task (tarefa) e guidance (guia) relativo a sua etapa do processo assim como pode ser observado na figura abaixo. Os guias estão posicionados na interseção entre Method Content e Process, pois podem expressar informações para as duas categorias definidas no EPF.


Iniciando uma instância do projeto a partir do processo definido no EPF


Na utilização do processo publicado através da ferramenta EPF podemos constatar um ambiente rico em conhecimento, contemplando, todas relações entre papeis, tarefas, artefatos e guias, permitindo obter mais detalhe sobre cada item do processo. Ainda é possível verificar as relações das fases como, por exemplo, inspeção e as atividades envolvidas, Gerenciamento, Modelagem de Negócio e Requisitos. Podemos verificar claramente tal situação, como ilustra a figura abaixo.



Um ponto forte na utilização do processo publicado foi à possibilidade de desempenharmos papeis mesmo estando separados geograficamente, através da uma intranet. Isso facilitou o desenvolvimento do projeto, principalmente nas tarefas de curto prazo.

Os guias podem ser uma grande ajuda uma vez que, tornam-se indispensáveis na busca de informações para desempenhar de forma eficaz algumas atividades, como por exemplo, em uma fase, etapa projeto, na atividade de definição de casos de uso, onde sentimos a necessidade de obter exemplos da especificação e diagrama de caso de uso ou de um outro diagrama dinâmico ou estático.

O processo definido no EPF Composer, aponta diversas vantagens com pode ser visto, atendendo a todas as nossas expectativas e superando as nossas necessidades, proporcionando assim, uma resposta rápida e eficaz as demandas dos stakeholderes.

Era uma vez o Java...será ????

Desde meu ínicio na carreira em Tecnologia da Informação, desde 1993 quando tive meus primeiros contatos com estágios não remunerados e remunerados em linguagem de programação e o mundo profissional de tecnologia da informação, com linguagens como C Standard para Unix e MS-Windows, Clipper 5.2d, lembram ??? MUMPS para AIX...bem eu começava em 1997, já antes do Java programava algumas automações de backup e aplicações de baixa complexidade em Python e SmallTalk com a ferramenta da IBM...também lembram ??? Assim comecei a ouvir de professores, colegas sobre a linguagem OAK ...mais tarde o Java, o querido Java do nosso depois mascote Duke que reuniria funções, tecnologias de linguaguens como C, C++, SmallTalk enfim ...uma boa invenção do nosso colega James Gosling, não vou ficar aqui fazendo trilha das linguagens que implementei e conheço e propaganda de uma linguagem e plataforma de desenvolvimento como o Java, não precisa não é ????
Mas então a Oracle conseguiu ??? O que ???
Iniciar a ação predatória dos cientistas da antiga SUN, cientistas tem seus métodos, seus cronogramas que não são parecidos com os cronogramas do mundo MakeBizz, não é ? Hoje podemos dizer que se a SUN não conseguir equalizar esta falta que Gosling fará ao projeto e sua continuidade, teremos muitas baixas de empresas que irá preferir estar com tecnologia similares como o Python e estável em sua continuidade, veja não entendem que estou querendo dizer o Java terminou, não é isso...mas sem Gosling perderá força !
A Oracle tem seu jeitão e não mudará já fez isto com o Weblogic, o servidor de aplicação mais estável na minha opnião profissional e hoje o Weblogic já mostra a nova cara com o jeitão da Oracle, não sei mais esperamos que a essência do Java não seja dilacerada.

Abaixo posto o blog pessoal do sr. James Gosling :
http://nighthacks.com/roller/jag/


O mundo do desenvolvimento de software hoje tem de abstrair estes STACKs de linguagens e convergir em uma unica notação ...

   

Será qual o caminho para implantar um ERP

Fazer a implantação de um sistema ERP é uma grande jogada, pois são considerados pacotes comerciais, desenvolvidos a partir de modelos-padrão de processos, visando à integração dos sistemas de diversas áreas da empresa. Isso quer dizer que você pode usar o sistema a favor do seu negócio correto? Correto, o sistema quando bem implementado, bem pensado, pode fazer o rendimento de a empresa mudar completamente.

 

A cultura da empresa muda, um projeto de implantação de ERP, além da preocupação com prazos, qualidade e custo é necessário uma gestão de conflitos e mudança. Uma empresa que tem uma cultura de empresa setorizada não consegue trabalhar de uma forma integrada, onde o serviço de um setor depende da finalização do serviço de outro para ser concluído.

 

A empresa após a implantação do ERP tende a ficar integrada, as grandes empresas pensam em ERP para gerenciar a sua informação, porém se a empresa não tiver uma maturidade não terá sucesso na automatização do seu processo, neste momento a profissão de gerente de projetos , gerente de projeto de software, arquiteto de software, tem um valor inestimável, pois o sucesso de uma implantação correta faz com que a empresa se torne muito mais competitiva no mercado e o retorno sobre o investimento seja mais rápido, no caso de uma implementação ruim, errada, tendo diversos retrabalhos e a companhia ficará muito vulnerável aos competidores.

 

Como é um processo de implantação de Projetos de ERP

 

O processo de seleção quando está adquirindo uma solução corporativa não é simples, envolve tempo, responsabilidade, e união da equipe estratégica da empresa, bem como um objetivo claro da real necessidade da empresa de conter uma solução que automatizará processo.

 

Se uma empresa apressa-se em instalar um sistema empresarial sem ter um claro entendimento de suas implicações para o negócio, sem uma definição clara de seus requisitos funcionais, o sonho da integração pode tornar-se um pesadelo, assim como a não definição clara dos requistos não funcionais para a integração de serviços.

 

Existem diversas maneiras de se implantar um ERP, as consultorias geralmente se utilizam de uma mistura de métodos até chegar a um modelo padrão.

 

Existem empresas de Software que possuem uma metodologia própria de implantação, customizadas por elas mesmas através de suas experiências, algumas situações o cliente indica alguma metodologia dele. Essas metodologias geralmente são pesquisas realizadas de projetos anteriores, o que chamamos de lições aprendidas com sucessos e insucessos.

 

A empresa alemã SAP desenvolveu o método ASAP de implementação de projetos que tem uma grande eficácia, a SAP compreende o seu projeto de implantação com base nas ações padrões da metodologia deles.

SAP AG
 

1 - Project Preparation – ASAP

 

Project Preparation é o inicio do projeto, nele são definidos os Key-Users (Usuários Chave), bem como planejado toda a definição estratégica do sistema.

 

Neste processo as definições a seguir são seguidas:

 

- Definição do escopo de implementação.

- Definição da estratégia de implementação

- Definição da organização e padrão de documentos.

- Definição do cronograma da implementação

- Treinamento da equipe de projeto quanto ao método de implantação

 

 2 -  “Business Blueprint” – Modelo dos Processos de Negócio

 

O principal objetivo desta fase é gerar um documento denominado “Business BluePrint”, contendo os cenários, processos e os requisitos de negócio da empresa.

Neste processo as definições a seguir são seguidas:

 

- Definição da estrutura organizacional da empresa;

- Desenho dos processos;

- Revisão dos processos de negócio;

- Documentação do escopo/desenho dos processos;

- Treinamento da equipe de projeto nos processos abordados.

3 - “Realization” – Realização

 

O propósito desta fase é a execução do “Business Blueprint“.

 

Neste processo as definições a seguir são seguidas:

 

- Parametrização do sistema e da estrutura organizacional;

- Desenvolvimento e Customização dos processos baseados no “Business Blueprint“.

- Criação dos perfis de autorização;

- Testes integrados.

 

4 -   “Final Preparation” – Preparação Final

 

O objetivo desta fase é analisar e preparar o projeto para o Go Live.

Nesta fase as tarefas principais são:

- Plano de entrada em produção;

- Teste da carga de dados/Volume de dados;

- Treinamento dos usuários finais;

5 - “Go Live” – Entrada em Produção

 

O propósito desta fase é a entrada em produção do sistema.

Why use the model driven architecture to design and build distributed applications?

[1] unifies and simplifies modeling, design, implementation, and integration of applications -- including large and complex ones -- by defining software fundamentally at the model level, expressed in OMG's standard Unified Modeling Language® (UML®)

[2]. An MDA-based development goes through three steps -- two producing models, one producing code -- and typically iterates through these several times.An MDA application's base model specifies every detail of its business functionality and behavior in a technology-neutral way; in MDA terminology this is the application's Platform-Independent Model (PIM). Use of well-known patterns, imported into the model from a library and parameterized to suit the application, speeds development and reduces error while still producing a complete and detailed PIM. Technology independence allows domain experts to concentrate on getting the business process correct, and preserves the model's usefulness beyond the technology churn cycle.Working from the PIM, MDA tools follow an OMG-standard mapping to generate an intermediate model tailored to the target middleware implementation platform. (OMG is standardizing mappings to all popular middleware platforms; several have already been adopted.) Termed a Platform-Specific Model (PSM), this intermediate product adds non-business, computing-related details (typically affecting performance and resource usage), possibly following "markup" inserted on the PIM by your architects, and the version produced by the MDA tool will probably require some hand-tuning before it can be used for the next step. (The amount of hand-tuning required will vary depending on the sophistication of the tool, the complexity of the application, and the maturity of the MDA in your application domain.In the final development step, working from the PSM, MDA tools generate interface definitions, application code, makefiles, and configuration files for the PSM's middleware platform. Because the industry has been working on this transformation for years already, and the model is tailored specifically for this transformation, the automated conversion in this step is typically 100% or nearly so. Performing a "build" on these artifacts yields a deployable application.Because the PIM is middleware-neutral and conversion to the PSM and then to the implementation is mostly automatic, it is practical to produce equivalent implementations of MDA-based applications on multiple target platforms. In addition, tools can generate cross-platform invocations, allowing easy interworking among suites of MDA-based applications wherever they reside. Another benefit of the MDA: because industry standards defined as an MDA PIM are platform-independent, they can be implemented on multiple targets and then used by every enterprise even in industries that haven't converged on a single middleware platform.Based on UML, automation, and sound architectural principles, the MDA supports applications over their full lifecycle starting with design and moving on to coding, testing, and deployment, through maintenance, and eventually to evolution to a new platform when an application's existing platform becomes obsolete. The MDA became the base architecture for OMG standards in September 2001.
OMG's Model Driven Architecture® (MDA®)

Think use Model Driven Architecture ...development with agility, unique entry point when begin construction, tests and deploy.