Mostrar mensagens com a etiqueta lógica de negócio. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta lógica de negócio. Mostrar todas as mensagens

domingo, 19 de junho de 2011

Dr. Strangesoftware

Stanley Kubrick, no filme Dr. Strangelove, constrói uma situação em que os homens ingloriamente lutam contra os procedimentos que criaram. Estes procedimentos, uma vez activados, iniciam uma processo que se revela impossível de parar, levando à destruição da vida no planeta terra. Esta história, é uma versão soft do tema que foi recorrente na ficção científica sobre a tentativa da máquina controlar o seu criador, o homem. Nestas histórias ilustra-se a luta entre a lógica e o humano.

Numa história real, Barbara Tuchman descreve num livro sobre o primeiro mês da Grande Guerra, The Guns of August, como o Kaiser, poucas horas depois de ter ordenado o início das operações contra a França, resolve, após receber um telegrama do seu embaixador em Londres, alterar a sua decisão e invadir a Rússia. A invasão da França tinha sido logicamente preparada para ocorrer em 6 semanas, o que implicava um minucioso plano de deslocação de cerca de 1.000.000 de homens, usando os caminhos de ferro. Quando o Kaiser comunica a sua decisão ao seu chefe do estado maior, a resposta que recebe foi, escreve Tuchman: 

"Your Majesty, it cannot be done. The deployment of millions cannot be improvised. If Your Majesty insists on leading the whole army to the East it will not be an army ready for battle but a disorganized mob...". 

O Kaiser não teve poder para parar a máquina que tinha colocado em marcha.

Também no software há este paradoxo entre a coisa criada e o criador, entre a lógica e o humano.

Num artigo recente na ACM Software Engineering Notes, Robert Schaefer descreve magistralmente este paradoxo:

"I’ve also been thinking a lot lately about the kinship that software developers and managers have in regards to the parable of the blind men and the elephant. Software, as an object stripped away from culture, can be reduced to mathematics, a culturally valueless set of rules of manipulation of symbols. Software also is the formalization of ideas into logic. Coding is nothing more than thinking clearly and logically in the process of symbol manipulation. If so, then what is the big deal? Why can’t just anyone write programs and logic be damned? Logic has one set of rules and culture another. Logic must, but cannot be, separated from cultural values (another paradox). The attempt to map cultural values onto logic, while denying that we are doing it as we do it, is where trouble begins. Now the blind men weren’t able to see the elephant all at once, they could only guess at parts through touch, and emphasize the attributes, assume the whole of a part. We though, as designers and programmers can see the whole elephant, but are not much better off. Which more or less ruins the elephant analogy. Unless the elephant we see is not the elephant that is. Then the elephant analogy works again. We model the elephant in our minds, but the elephant that is, is something different. It looks like an elephant, but behaves like something else. In this instance, it looks like logic but behaves like culture."

Há, no entanto, uma diferença fundamental relativamente às máquinas e procedimentos que têm por base uma visão científica enraizada em princípios desenvolvidos ainda no século XIX: no software a coisa criada não é externa ao criador, não existe para além dele.

Dessa propriedade do objecto de software, que é a sua apropriação pelas pessoas, para além da lógica, falo em alguns dos posts. Por exemplo Da desordem à ordem natural das coisas é sobre a necessidade de tornar a codificação da cultura mais integrada com a codificação da lógica.

terça-feira, 29 de março de 2011

Onde pára o conhecimento

Há algum tempo atrás fui contactado pelos responsáveis do sistema de informação de um organismo público. Não estavam satisfeitos com a empresa de software que desenvolveu e mantinha o seu sistema de informação e pretendiam proceder a uma reimplementação, usando outra tecnologia. A mudança de tecnologia era a escusa para a reimplementação do sistema de informação. De facto, a tecnologia alternativa que se propunha era muito semelhante, em termos das suas capacidades, com a tecnologia existente.

Após conversamos um pouco, apercebi-me que a empresa de software detinha o conhecimento do negócio do organismo público. A empresa de software tinha um melhor conhecimento do negócio do organismo público que os responsáveis do sistema de informação. Esta situação tinha levado a uma situação de dependência. Os responsáveis tinham a sua capacidade de decisão limitada.

Como se chega a este tipo de situação? Neste caso o desenvolvimento seguiu o modelo outsource. Foi desenvolvido um sistema de informação à medida. Geralmente, sempre que  se desenvolve um sistema de informação geram-se as condições para tornar explícito o conhecimento acerca da organização. Durante o processo de levantamento de requisitos, e mais tarde durante o desenvolvimento, vão-se identificar e tornar explícitas as regras de funcionamento da organização.

Um vez tornado explícito o conhecimento sofre várias transformação na forma como está representado para poder ser executado num computador. A sua representação final está incluída do programa que implementa o sistema de informação. Os engenheiros informáticos que participam neste processo ganham um conhecimento profundo sobre o negócio da organização. 

E é aqui que o problema começa. Numa situação de outsource, a organização recebe o sistema de informação mas não recebe necessariamente o conhecimento. De facto, e um pouco paradoxalmente, até perde conhecimento. A automatização trazida pelo sistema de informação faz com que o conhecimento fique transparente para as pessoas que operam a organização suportada pelo sistema. Ou seja, o conhecimento, que estava implicitamente nas pessoas da organização, é tornado explícito e incorporado no sistema de informação, onde fica de novo implicito. A manutenção do sistema de informação, efectuada pela empresa que o desenvolveu, é de facto a manutenção desse conhecimento.

Nesta situação a dependência torna o organização contratante o elemento fraco da relação contratual. E os custos poderão aumentar.

Existem diversas formas de tentar manter o conhecimento dentro da organização. A mais drástica que tive conhecimento foi uma instituição bancária que resolveu adquirir a empresa de software que desenvolveu alguns dos seus sistemas de informação. Um exemplo de passagem de desenvolvimento outsource para in-house. Mas administração pública não tem essa capacidade. Assim tem que procurar manter o conhecimento internamente através dos seus recursos humanos, mas também aí tem que contar com a competição das empresas de software na contratação desses recursos.

Como resolver este problema, no contexto da administração pública, sem voltar ao desenvolvimento in-house? É necessário que a organização não perca o conhecimento. Mais ainda, deve procurar que ele seja público. Para isso, deve ser externalizado, por exemplo participando em organizações de normalização. Por outro lado, deve procurar motivar o aparecimento de comunidades (virtuais) que estejam interessadas na manutenção desse conhecimento. Poderão ser comunidades de utilizadores interessados em discutir como o serviço pode ser melhorado, ou comunidades de cidadãos interessados em auditar o funcionamento da organização. Também se poderá usar o conhecimento na formação, interna ou externamente. Ou seja, o conhecimento deverá ser aberto um pouco por analogia com o software aberto.

A administração publica deve possuir conhecimento aberto para aumenta a sua capacidade negocial  nos concursos para o desenvolvimento e manutenção dos seus sistemas de informação.

domingo, 6 de março de 2011

Da desordem à ordem natural das coisas

"Segundo as teorias mais recentes, a Terra na sua origem seria um pequeno corpo frio que aumentaria depois englobando meteoritos e poeiras meteoríticas.

Ao princípio iludíamos-nos de que conseguiríamos mantê-la limpa -- contou o velho Qfwqf -- ..."

Durante o desenvolvimento de sistemas de informação existe a preocupação que incluam o conhecimento sobre o negócio a que se pretende dar suporte. Este conhecimento, normalmente referido como a lógica de negócio, é determinante no impacto que o sistema de informação vai ter na organização onde será instalado. Passa-se de uma organização onde o conhecimento se encontra nas pessoas, e que depende delas para o seu funcionamento, para uma situação em que o sistema de informação orienta as acções das pessoas de acordo com a lógica de negócio que implementa.

São inúmeras as vantagens do sistema de informação incluir a lógica de negócio. Para além da normalização do funcionamento do negócio, permite automatizar muitas acções reduzindo custos, e assegurar que as regras definidas são seguidas.

Antes da instalação do sistema de informação, é frequente que a organização possua um reduzido nível de controlo, a eficiência seja baixa, aconteçam muitas situações de erro, haja dados incoerentes e não seja possível obter-se a informação que se necessita com facilidade. Neste contexto, o impacto da instalação do sistema de informação é o de arrumar a organização.

"...A Terra começava a ficar tão grande que já nem todos os dias Xha conseguia ter tempo para a correr toda..."

Contudo, mesmo que se deseje, não é possível incluir todo o conhecimento acerca do negócio no sistema de informação, e mesmo se isso fosse possível a sua utilização faz surgir novas situações que não estavam abrangidas pelo corpo de conhecimento inicial.

Por outro lado, quando o conhecimento passa das pessoas para o sistema de informação acontece um fenómeno de desresponsabilização. Sendo o sistema detentor do conhecimento, as pessoas que o utilizam passam a delegar toda a responsabilidade do que acontece, positivo ou negativo, no sistema.

Contrariamente ao que ocorria antes, em que não obstante a desordem, as pessoas assumiam os problemas como seus e eram pró-activas para a sua solução, agora, tudo o que o sistema não resolve é uma impossibilidade, não tem solução: O sistema não deixa!

"...Assim, qualquer objecto novo que caísse sobre o nosso planeta acabava por encontrar o seu lugar como se sempre ali estivesse estado, a sua relação de interdependência com os outros objectos, e a irracional presença de um achava a sua razão na irracional presença dos outros, a ponto de a geral desordem começar a poder ser considerada a ordem natural das coisas..."

Existem tecnologias que ajudam as pessoas a fazer o seu trabalho sem orientar as suas acções, como o correio electrónico ou os wikis. Mas estas tecnologias não suportam lógica de negócio, são tecnologias genéricas de suporte à colaboração entre as pessoas.

Um dos actuais desafios da engenharia de software é criar as ferramentas que orientem as acções das pessoas mas não as desresponsabilizem. Que a lógica de negócio não iniba a reacção e o tratamento do imprevisto. Que o que não foi considerado no desenho inicial do sistema possa ser relacionado com o que foi tomado em consideração. Os sistemas de informação, e as tecnologias sobre os quais são desenvolvidos, deverão passar a ter embutidos de raíz funcionalidades semelhantes às do correio electrónico e dos wikis.

O texto entre aspas foi transcrito do conto Meteoritos de Italo Calvino, publicado pela Editorial Teorema, no livro Novas Cosmicómicas, numa tradução de José Colaço Barreiros.