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.

Software Design, software implementation and software architecture are with same origin, but "DNA", NOT EQUAL or <>

Design, and implementation, are terms software architecture, are typically used informally in partitioning software specifications into three coarse strata of abstraction. Yet these strata are not well-defined in either research or practice, causing miscommunication and needless debate. To remedy this problem I think with criteria of distinction between architecture, design, and implementation is qualitative and not merely quantitative.
I try demonstrate, with my position with my buddies of team project in customers and my project management, VP Technology of alliance and customers that architectural styles are intensional and non-local and that design patterns are intensional and local and that implementations are extensional and local, this definition also with influence of my professional buddy, mr. Amnon H. Eden of Center for Inquiry, Amherst, NY, and Department of Computer Science, University of Essex, United Kingdom, I participate of two projects with this "GAON", expert IT professional. Your influence help me with these definition and position together my teacher Dra. Mara of Rio de Janeiro Univeristy and some years old of my professional experience, that one Architect must be one programmer + software designer with action of head technical.

In their seminal article, Perry and Wolf [24] developed “an intuition about software architecture through analogies to existing disciplines.”

If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
— J. H. von Neumann

“Architecture is concerned with the selection of architectural elements, their interaction, and the constraints on those elements and their interactions… Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.”


The Intension/Locality Thesis

To elucidate the relationship between architecture, design, and implementation, I try distinguish at least two separate interpretations for abstraction in our context:  Intensional (vs. extensional) specifications are “abstract” in the sense that they can be formally characterized by the use of logic variables that range over an unbounded domain;  Non-local (vs. local) specifications are “abstract” in the sense that they pervade all parts of the system (as opposed to being limited to some part thereof).

Both of these interpretations contribute to the distinction among architecture, design, and implementation, summarized as the Intension/Locality thesis:

(A) Architectural specifications are intensional and non-local;
(B) Design specifications are intensional but local; and
(C) Implementation specifications are both extensional
and local.

Why, my interested in such distinctions? I also of many professionals of software engineering of distinct these topics.

Arquiteto de Software ou Programador Senior ou Analista de Sistemas Senior ???

Software Architect or Senior Programmer or Senior System Analyst ?

O que 'e isto ? O que 'e um arquiteto de software ?
Esta posicao profissional existe nas empresas latino americanas ? Existe nas empresas brasileiras ???

Sim, em algumas empresas existe SIM ! Muito poucas existem bem definidas...

Mas na maioria acreditam que um arquiteto de software deva ser um programador senior e um analista de sistemas senior, os dois ! Ou um dos dois. Veja que para se chegar a ser um bom arquiteto de software com CERTEZA, ele teve um dia o papel dedicado de um programador senior, analista de sistemas senior, alguns ate um analista de suporte, mas ele, ele quem ???
O profissional formado em tecnologia da informacao e carreira de base matematica, com pelo menos experiencia em algumas linguagens de programacao, ambiente de sistemas operacionais e estrutura de processamento, que tambem especificou definicoes nao funcionais e funcionais em notacao UML, assim cumprindo o papel de arquiteto de software de um projeto de software. Portanto o mercado de TI NECESSITA deste profissional cada vez mais no Brazil ou Brasil, mas cada vez mais ha uma BAGUNCA nos conceitos e objetivos desta posicao profissional que se confundem com os analistas de sistemas e que assim sao responsaveis pelo design da aplicacao e que trabalham em conjunto com os arquitetos de software, assim como a implementacao fica a cargo dos engenheiros de software, programadores seniors, pleno e juniores, hoje muitos projetos de software se classificam em risco ALTO de resultarem em negativas informacoes nao esperadas pelas empresas, por motivo de nao conseguir mitigar os requisitos funcionais e nao funcionais para uma arquitetura de software boa, desenvolvida de uma forma bem definida e classificada de acordo com o requerimentos a alcancar pelo projeto.

Acredito que estamos em uma fase TRIASSICA na arquitetura de software, muitos irao confundir os papeis, posicoes profissionais e funcoes...

O arquiteto de software de uma aplicacao 'e um profissional que atua em um nivel acima de programadores, analistas de sistemas e DBAs. Sua funcao tem como objetivos compor uma solucao, dado os requisitos de uma aplicacao distribuida ou nao, utilizar as tecnologias disponiveis.
'E responsavel por tomar decisoes tais como :

• A linguagem de programacao esta adequada a escolha para solucao ?
• Havera ganhos reais em encapsular a logica de negocios em EJB ou CORBA ?
• Havera ganhos de mudarmos alguma estrutura ou adicionarmos uma estrutura nova de aplicacao no projeto que ja funciona ?
• E suficiente esta arvore de objetos para tratar, mitigar, validar as informacoes da aplicacao ?
• A aplicacao web estara suficiente seguindo o modelo MVC ?
• As operacoes necessitarem comunicacao assincrona?
  
• Utilizaremos XML para interface com outras aplicacoes?
• Sera necessario disponibilizar WebService ?
• Existe um framework ? Vamos customizar ? Utilizar uma pronta?(Maioria dos casos)
  

• A aplicacao esta modelada orientada a servicos ? Ha necessidade ?

O trabalho do arquiteto de software ser'a em garantir que a aplicacao seja implementada de modo coerente, fazendo o melhor uso possivel das tecnologias empregadas e entregando valor real para os clientes e/ou usuarios da aplicacao com uma relacao custo/beneficio favoravel.

Abaixo a definicoes segundo alguns grupos, empresas que influenciam as atividades de arquitetura de software :

According to the Rational Unified Process: “Software architecture encompasses the significant decisions about the organization of a software system. The selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements. The composition of the structural and behavioral elements into progressively larger subsystems, the architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition. Software architecture is concerned not only with structure and behavior but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic issues.”[1] [1]
Author : Unified Process: An Introduction

That is a pretty lengthy definition, so let's look at a little simpler definition provided by the SunTone Architecture Methodology: Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole.[2] [2]
Author : Sun Microsystems, Inc.

O papel de um arquiteto :

“The ideal architect should be a person of letters, a mathematician, familiar with
historical studies, a diligent student of philosophy, acquainted with music, not ignorant of
medicine, learned in the responses of jurisconsults, familiar with astronomy and
astronomical calculations.”

Isto seria um sonho das empresas...

—Vitruvius, circa 25 BC

Vitruvius was not referring to a software architect, but the basic idea is that the architect
should have the following characteristics. An architect should be a person who is well-
rounded, mature, experienced, educated, learns quickly, a leader, communicates well and
can make the difficult decision when necessary. For architects to be well-rounded, they
must have a working knowledge of the business or problem domain. They can gain this
knowledge through experience or education. In addition, architects must have a broad
knowledge of technology. An architect might have first-hand experience with a particular
technology, but they must have at least a general understanding of competing
technologies to make informed decisions about which technology can work best. A good
architect evaluates all possible solutions to a problem regardless of the technology being
used.

O que um arquiteto de software faz ???

O que difere entre um arquiteto de software comparado a um programador senior ? Esta e um quetionamento COMUM.
O designer da aplicacao e construido, concedido com o que acontece quando um botao e pressionado e um arquiteto de software concede seu apoio como central a resolucao do problema com o que acontece quando 12(doze) mil usuarios pressionam o mesmo botao, entao aparece bem definida o momento que os engenheiros de software(analistas de sistemas/programadores) devem ter trabalho compartilhado com os arquiteto(s) de software do projeto, sendo que a reflexao do arquiteto de software deve estar participativo em todas as camadas do projeto, mas percebeu que o arquiteto de software influencia na arquitetura quando pressionar o botao, mas quem define sao os designers(os Analistas de Sistemas). Um arquiteto mitiga os riscos tecnicos associados com o sistema, riscos usualmente classificados com os niveis de servicos requeridos and podem ocasionalmente ser associados com os requisitos de negocio do projeto de software.

Existem certificacoes boas e associacoes no mundo e grupos formados virtualmente no Brazil com o objetivo de fortificar esta posicao, segue abaixo :

SCEA - Sun Certified Enterprise Architect (Java Enterprise Edition)
http://www.sun.com/training/certification/java/scea.xml

The Carnegie Mellon^® Software Engineering Institute (SEI)
http://www.sei.cmu.edu/architecture/definitions.html

International Association of Software Architects (IASA)
http://www.iasahome.org/web/home/home

OMG - Object Management Group
http://www.omg.org


* Eu coloquei parte do texto em portugues e ingles, pois para caracterizar nossa profissao que estes idiomas se entrelacam, pois entre engenheiros de software, arquitetos de softwares, programadores, DBAs nao existe varios idiomas apenas um : 0 e 1, ou seja comunicacao binaria !