sábado, 27 de julho de 2013


Você já parou para pensar que esse montante de certificação existente no mercado, é apenas uma forma de enganar os trouxas?.

Há quase 2 anos iniciei uma discussão no grupo de Governança de TI do linkedin que já ultrapassou mais de 170 comentários. Tentamos entender o valor das certificações em relação ao conhecimento prático, a conduta ética dos profissionais e o mercado crescente de treinamentos com garantia de certificações. 

Qual a sua opinião, você acha que as certificações realmente conseguem distinguir os bons profissionais?. 

No mercado existem duas empresas de certificação:
  1. Vue -> http://www.pearsonvue.com/programs/
  2. Prometric -> https://www.prometric.com/en-us/clients/EXIN/Pages/landing.aspx

OCEB da OMG e GMAT (testes para admissão nas melhores universidades do mundo) são exemplos de testes da Vue, bem como diversos fabricantes que confiam na instituição, como: IBM, Oracle, Microsoft, etc...

ITIL, COBIT e PMP são da Prometric.

Quando as provas são realizadas por esses centros, eles utilizam normas de conduta. Assim, eu acredito que o profissional possui algum conhecimento sobre o conteúdo da prova, embora isso seja questionável (explico adiante!).

Acontece que algumas certificações podem ser conseguidas através de prova em papel, inclusive sob a supervisão de quem treinou. Será por isso que enfatizam a garantia de aprovação nos exames CBPP, SCRUM, ITIL, COBIT e PMP?.
A certificação PMP é uma das certificações mais prestigiadas do mercado e mesmo assim é possível burlar o sistema, relatando que você possui o tempo de experiência necessário para fazer a prova. Assim, basta decorar tópicos do livro da Rita Mulcahy e treinar simulados para se tornar um PMP (Profissional Especialista em Gerenciamento de Projetos). A questão é: e depois?. Quando vemos péssimos gerentes, que parecem realmente não terem qualquer experiência, fica claro que eles nuncam gerenciaram um projeto na vida. Muitas vezes ninguém entende como estes "profissionais" são de fato PMPs. 

Está aí a explicação -> FALTA DE ÉTICA, denuncie ao PMI.
 
Quero enfatizar que muitas certificações prometem o que não podem cumprir. Na verdade, a promessa de distinção ao candidato que estuda e segue o processo legal é inútil, porque algumas organizações não fiscalizam todo processo como deveriam. Há brechas desde a inscrição até a realização das provas e não há como qualquer empresa saber quem fez provas em papel ou nos centros Prometric e Vue. Desta forma, eu considero a experiência, o verdadeiro diferencial para avaliar o profissional. Conforme frisado neste texto, a falta de ética ainda é um problema muito grave e pode trazer prejuízos as empresas.


segunda-feira, 8 de julho de 2013


FACTO Enterprise Architecture Framework: 

A Continuous Integration Environment in the Life Cycle of Enterprise Architecture

Abstract. An Enterprise Architecture can be a means to achieve the IT governance and thus it ensures a competitive advantage to the company. However, during his deployment there are a large number of difficulties; one of them is its integration with the software development process. This study provides a roadmap for institutionalizing, evaluating and deploying an Enterprise Architecture within the software development environment. The roadmap has established strategies to apply a framework from the perspectives of the company management areas, which have shown the differences between the current and desired architecture. Finally, it implemented a new architecture to solve systemic troubles in the business processes, where it was possible to manage all system issues on levels: strategic, departmental, software requirements, hardware solution and implementation code. Thus, this study contributes significantly to ​​Corporate Governance in a pragmatic way, because it illustrates how to align business and IT strategies using the Enterprise Architecture.

Keywords: Enterprise Architecture, Framework, Roadmap.

1 - INTRODUCTION

Zachman introduced his first glimpse at (Zachman, 1987), where the Enterprise Architecture characterize itself by using of informational layers, which has supported several companies from technical to business viewpoint of IT. After five years of their Framework defined, it rose to introduce other management skills. However, the Enterprise Architecture term was not used in 1987 and 1992, it was referred only to Information Systems Architecture instead. In 1996, when occurred the Clinger-Cohen signature, where federal agencies of the U.S. government building an approaching to align information technology to their business goals. Which led to creation of an Enterprise Architecture in a well-known way concerned today (Langenberg and Wegmann, 2004).

Among year of 2004 occurred a survey based on some criteria, which found 80 articles, which there was an outspoken reference to the term "Enterprise Architecture". This result confirmed that, despite being a young discipline in the computer science, their interest was growing by the academy. The main authors were mostly consultants' firms and academics, but the academics were least contributions about the approach. In assessing, the authors hoped a growth interesting and recognition this approach, mainly with focus on their adoption by companies, if these could also publish theirs experience reports. The wide dispersion of publications can, in this time, figured out the approach as young as immature (Langenberg and Wegmann, 2004).

After decades of studies, few practices framed within the firms, despite their benefits already had enough known in this time. There were several problems on the approach, mainly caused by a modest involvement of the industry, which was believed after infer about the subject' dispersions related to the Enterprise Architecture adoption (Langenberg and Wegmann, 2004).  

Nowadays, with software engineering emergence, new approaches has leading to advanced practices, such as Model-driven Architecture (Silva, 2011), Service-oriented Architecture (OASIS, 2011) and Agile Development (Cockburn, 2006), which was possible to found some targeted work. An example is a recent study (Carrillo et al, 2010). They faced to the challenge of building an Enterprise Architecture within a higher education institution, and to make easy their adoption. However, their processes were disperses in the life cycle architecture and it was an obstacle. Unfortunately, this problem and other related to Enterprise Architecture adoption is common in a software development environment, and there has motivated our research about this subject.
 

This study contributes to a hybrid approach, what inserts management models into the Enterprise Architecture life cycle, which progresses in a process-driven way. As a result, their set of processes (e.g. projects management, application portfolio management, software development, quality and their shortages) have helped the stakeholders to manage actions and visions performed for them, which has promoted an improving in the business units.

This paper presents our experience by using this approaching in the firm. The Section 2 reports the motivation and the Section 3 the steps suggested. Our considerations and references used to conceive this work are at the end part of this work.

2    MOTIVATION

After a series of workshop presented within the company, we figured out by itself the need about to know details about the Enterprise Architecture. As a result, the IT projects were not ensuring fully the company's strategic and vision, also the mechanisms to audit these projects. There was a workshop, at same time where the main business area of company presented their entire value chain and problems to achieve their goals and objectives within the business units.

All active projects had a real need of governance and management models, beyond of patterns about software engineering practices in the company. Notably, viewpoints combined on a holistic system, which was fundamental for entire arrange, thus we think about it quickly provides answers to stakeholder and their questions based on a range of enterprise perspectives (i.e. business strategy and project management processes, systems and technical support).

From organizational viewpoint there was not a comprehensive treatment, but as well specific and limited according to polices and rules these models. Mainly to ensure the attendance of several stakeholder viewpoints and alternatives to build a solution which could converge at risks reduction, at same time that it will provide their management models improvements in the firm.

3    OUR EXPERIENCE REPORT

The FACTO approach has facilitated the building of IT projects, the improving of communication, collaboration and understanding of business unit goals in an arranged way. The FACTO also ensures the effective use of IT by aligning their business strategies to leverage a competitive advantage, meanwhile raised deeply the customer satisfaction by achieving your goals on their business processes.

The approach also allowed different views, in order to promoting and arranging of their parts faced of several stakeholders' perspectives and profiles about the suitable architectural details. Besides serving as a baseline to use Service Oriented Architecture (SOA), it helps other integration forms among the enterprise systems (e.g. legacy systems and software packages in bought process) in various kinds of businesses (Shah and Kourdi, 2007). According to handicap faced in this work (Section 2) there was a need of a hybrid approach to integrate a software process model within the new architecture life cycle.

The roadmap began from a business strategies understanding, analyzing their issues and deepen the knowledge about IT parts. What featuring an evaluation of the main company perspectives to ensure an integrated stakeholders view by providing a guide for setup an Enterprise Architecture in a software development environment. Our study aimed to: (i) organize the software development department in line with multiple stakeholder viewpoints, by using this approach for designing of the new architecture; (ii) create practices to support management and governance IT model in the architecture, that includes artifacts approval as well as their templates; and (iii) provide support to business changes quickly and an immediate presentation of results in according to project management office in the enterprise.

 3.1    The Institutionalization Step

The adoption of an enterprise architecture meant to achieve integration and alignment between information technology and business objectives, as well customize our needs according to own culture, policy and  procedures of firm. The institutionalization needed a special role with a deep knowledge about software engineering techniques and methods, at same time where the purposes a team should have more responsibility to certify the IT investments and their accuracy either. Meanwhile was being fulfilling a range of technical needs and business goals within the enterprise architecture. The preliminary phase was important for outcome actions on the institutionalization steps related below, while the business issues identification and alignment between business and IT strategies.

Table 1 – Business Questions.

  • The first action was to analyze the initiative in according to projects scope, which everyone could have a unique insight into the aims of reason for their creation, people involved and how would harass their goals. The business units questions figured out on the processes, such as shown in the Table 1, presents a first direction to architecture, which their issues can be found. For example, software requirements on software engineering field, ideas about software specification, needs and development environment. This process step always helped over a short and long-term goal, problems in drawing of architecture specification, and understanding of software developing environment to fulfill the business and IT strategies settled by the company's business units (Song and Song, 2010).
  •  The second action was to compare the enterprise architecture strategies according to business issues and to distinguish them of IT strategies. This step was important to identify assets of company, specially, when it includes the people on that environment if it can or cannot have some direct actions with software systems, business processes, hardware devices, infrastructure technologies, and other IT resources (Song and Song, 2010). Afterwards, we have formed an enterprise architecture team, where people would effectively perform a whole transition to new architecture. 
  •  The third action was to describe a current state of enterprise architecture (As-Is), in this step was necessary to identify the hidden assets, gaps and redundancies IT resources in different business units based on stakeholder's views. A defining method for the early enterprise architecture was to arrange information in according to architectural viewpoint, as proposes (IEEE, 2000). Each one of four architecture layer composed of distinct blocks, which in turn, further broken down into levels of modules, software packages and their parts.
The scheme built in Zachman (Zachman, 1987) has a reference to the enterprise architecture building (As-Is) and covers a large dimension for strategic alignment, which links business and IT strategies, by reflecting from external focus to business units. Another integration figured out above suiting to internal concerns, namely, a link between technological view and presentation of data. The found dimensions considered for each concern in a cell field, specifically how choices within the IT projects threatened on business units domain achievements and conversely. The guide offered a strong guideline to knowledge necessary, to get enterprise architecture lines (above and below) and compliance of software project artifacts. This approach also needed a good knowledge about the fields those crossing relationships, where business strategy was a value driver and IT strategy as a helper.

When chosen the architecture goal, at same time which presented an analysis of differences about their reference (As-Is) and target (To-Be) architectures, the business tactics has changed. There was a building of a strategic planning to identify gaps in this transition step process (Table 3). Which all gaps found in business units, presentation data layer of software applications and technical infrastructure layers directed to a new architecture design (To-Be). Afterwards, when was analyzed their deficiencies, then occurred an expansion of the real needs across of stakeholder viewpoints, which includes the political and technical obstacles. In addition, a risk analysis to enable the new architecture transition. As matter of fact, it was believed that the correct alignment between organizational and architecture vision, would enable a better integration among norms and standards, according to management systems and hardware, what have occurred since then. These standards have helped to dictate rules to ensure interoperability between different systems and stakeholders viewpoints in the firm.

3.2    The Evaluation Step

Our proposal used the Odongo et al (2010) evaluation, which was based on the failure on treatment of enterprise's perspectives due to fact that are not used properly when your adoption. Mainly, by lack of skills about assess an Enterprise Architecture Framework. Because of the companies have still a great difficulty to fitting EAF in front of your business prospects. Their proper selection can play a crucial role, which transforms a software requirements specification in a system and it involves on both: software and hardware integration skills.

The followings perspectives were evaluates according to Odondo et al. (2010):
  1. Goals: Goals are for accomplishment, involvement, problem area, time frame, requirements, and constraints. 
  2. Inputs: EA inputs outline integrated processes and goals in a business enterprise to provide process components.
  3. Outputs: Outputs are used to understand the gaps that exist when planning for the preferred future environment.
  4. Views: Views are depictions of the complete architecture, for communication, EA understanding, and verifying system.
  5. Abstractions: Abstractions enforce a progressive decomposition and maintenance traceability of EA design for detailed implementation.
  6. System development life cycle: The SDLC process consists of defined processes, and roles, and responsibilities.
  7. Guide: The guiding process defines, maintains, and implements EAs by providing a disciplined approach to EA life cycle management.
  8. Quality: Software configurations change and attaining quality attributes confirms whether a good job has been done.
  9. Miscellaneous: This perspective contains important aspects that are not covered in other perspectives.
  10. Requirements: Determines EAFs representation, lessens risks, allows changes and alignments, and integration.
  11. Principles/Rules: Define the fundamental rules for the use and deployment of all IT resources and assets.
Almost all perspectives were met and established by the company, which includes: support to multiple views, strong relationship with a software process model, supporting to specification and solution architecture, management and increasing to software artifacts reuse, beyond of flexibility on the business process changes and project management. Clearly, each one offered certain advantages over other frameworks. Among the enterprise architecture frameworks evaluated, none them completely met all perspectives established by the company. However, each one has offered certain advantages over the others:

The TOGAF (The Open Group Architecture Framework) is the latest and most detailed among them, however it is highly methodical and needs improvements to establish management standards (Buckl, 2009). This EAF can be very useful to apply with a methodology for agile projects management in multiple system design with high complexity and low scalability.

The TEAF (Treasury Enterprise Architecture Framework) was created to support the business processes of the U.S. Treasury, it provides a guide for building and designing business processes for purposal of meeting the legislation requirements in an agile environment, which enables quick changes on business process. It can be best applied where the functional and organizational architectures must be seen jointly with a vision of model processes, procedures and business operations.

The DoDAF (Department of Defense Architecture Framework) provides a set of views and it can act as a mechanism for viewing, understanding and assimilating the architecture scope and complexities. It is especially suitable for large and complex systems and interoperability challenges among the systems interfaces.

The FEAF (Federal Enterprise Architecture Framework) was initiated by the Office of Management and Budget of the U.S. to comply with the Clinger-Cohen Act providing a common methodology for the IT acquisition across of the federal government of the United States. Therefore, it adheres more readily the projects perspectives that aimed at sharing information and resources between federal agencies, costs reducing and improving services to citizens (maybe it could be applied on Brazilian government).

The Zachman Framework was the first EAF, its elements are half formal and highly structured by a classification model and using two dimensions, based on six basic communication prerogatives: What, How, Where, Who, When and Why. It goes well for firms that has a big communication mistakes and absence of collaboration structure.

3.3    The Implementation Step

The assessment model based on the firm's perspectives and followed by Odongo et al (2010) proposal. Although proposal clearly has an easier scheme for selecting and define an enterprise architecture framework,  none of them could entirely ensure the compliance to company's perspectives. One of main problems found, as matter of fact, were found in a high abstraction level what would not aligned so easily to working with specific concerns. What happens often in several cases. Thus, was needed fitting with existing management areas (i.e. applications portfolio management, software development process and project management).

The project of an enterprise architecture adoption was very important to check the entire attendance of company's perspectives. Whereas already mentioned on the evaluation process steps this work, how to meet the basic stakeholders viewpoints by using business questions and views. A good practice could be to collect these viewpoints by using Business Process Management or BPM. (Silva and Saba, 2008). A set of activities could be met based on their objectives, goals and priorities, by making easy their adherence to project management and software configuration models that are running into the company.



 Figure 1 – The FACTO Process Areas.

Such as seen until now, there is not the best Enterprise Architecture Framework, yes that adheres better to company's perspectives and offers a solid and feasible proposal to remedy existing problems. The creation of process areas (Figure 1) based on the staff experience, what provides agility and more flexibility in the approach to build an enterprise architecture in according to our reality. Since they already had knowledge about the project management office practices, the PMBOK guide (Silva and Saba, 2008) was used to promote a centralized approach to active projects. Consequently, it helped the new architecture adoption. Also, the CMMI (CMMI, 2006) has defined a certain maturity level to enterprise architecture, and it ran with the Crystal methodology (Cockburn, 2011), which ensured the architecture planning over and collaboration among stakeholders. In addition, the old-fashioned architecture problems in relation to new, wherever to adherence for the new software process model has a dramatic growth. The PDCA cycle (Silva and Saba, 2008) contributed to ensure a standards about the correct procedures in a set of activities of new software development process and their metrics for assertion.

There was a selection of the main transition requirements from the reference to the target architecture, in order to implements the new enterprise architecture. Their planning started with the steps defined to specify and resolve issues about the new architecture and must be aligned to software configuration and capacity planning, in addition to their integration, development and software testing. Thus, all processes areas were built in according to ours perspectives and goals within the architecture life cycle. Meanwhile the stakeholder viewpoints and their abstractions were conducted in according to organization's perspective within the continuous integration architecture. 

On condition that enterprise architecture there has been guided by principles and rules, other perspectives were also added for unblock cultural barriers and improve the collaboration among stakeholders. Also, an easy language to alignment business units and IT strategies allowed its use, which includes a weekly meeting for encouraging of new ideas and to providing a software development safe environment.

The roadmap for enterprise architecture implementation from company's perspective enabled to solve inherent troubles on stakeholder views and to support fast business changes in the software development environment. It did contribute with your solution to treatment of deficiencies found meanwhile the implementation phase. The process areas and an integrated view promoted to managers and leaders manages each process area of the FACTO.

  Figure 2 – The Continuous Integration Environment built.

The final step was to ensure the architecture transition goals followed by every one of stakeholder involved on the business units. Clearly, the coming of agile principles such as Crystal (Silva and Saba, 2008) turned over possible ensuring the main goals and objectives of software development process within the architecture life cycle. Finally, the Continuous Integration Architecture (Buteau et al, 2009) offered more security, and team's commitment growth. This approach emerged to success of several software projects by have facilitated also to verify and certify programming codes by using metrics to compliance. Overall it corroborates an automation of unit testing, integration testing and deployment testing of new built parts, consonant to stakeholder needs in the business units.

The Figure 2 shows the final Continuous Integration Architecture project. All required items were supported by a version control system (Buteau et al, 2009). The version control system ensured a certain governance level, in addition to file definitions schemes (i.e. database, POM file, and project solution) and software projects. There also a role to perform the software management and only this role can make any changes on the project artifacts. Always there is a software architect who must be always up to the best vision and an entire alignment with the business units and IT projects for certifying it.

The software development environment separated by interests and goals, what reduced unnecessary access to production servers, where the software applications stay officially after approved to use by the company and by controlling information security incidents. The local machines used by software developers replicated on each application servers, used to software developing and testing. There is a released access to current version of software artifacts per team profile either, in according with each profile configured on the version control system. In our work the continuous integration architecture perform on management environment (Buteau et al, 2009), which provided quickly and easier evaluations about the unit and integrated testing. In the same way that the software dispatched to deployment and distribution in the certified application servers (applications servers that perform functional testing) for their accreditation automatically.  

Some Hudson plug-in ensured the dispatch of alerts and e-mail warnings to software developers. This approach improved on our overall productivity and flexibility on the project scheduling and control in the software development phases. As the main result this automation, there was an increased assertiveness of software developers towards systems requirements. What also contributed to a new transition architecture adoption, throughout the software development environment in the firm.

4    CONCLUSION

Afterward decades of studies about Enterprise Architecture quite a little became practice in companies. Several studies have sought to solve some troubles related to their adoption with a modest involvement of the software industry. In recent years, by the emerging approaches, which led to advanced practices on software engineering, was possible figured out some promising approaches. However, when a Enterprise Architecture is running on the software development environment, there was a list of difficulties found. Mainly, the dispersion of its artifacts in front to architecture life cycle, which turned it into a major obstacle for its adoption.

This work suggested a better integration among the software development process and how it performs itself within the Enterprise Architecture life cycle, what includes a roadmap for its correct institutionalization, assessments and implementation, according to business units perspectives and stakeholders viewpoints. The FACTO Enterprise Framework has promoted improvements in the software development environment, at same time that ensured a better understanding of the business units needs and stakeholders viewpoints. Thus, the collaboration among the people grown, and their support to multiple views in the Continuous Integration Architecture. The agility to apply software architecture styles and models, templates, and automatic testing for programming languages has increased quickly, also its assertion on the software components. Finally, the FACTO process areas were built on best practices and has solved many problems related to strategic and technical alignment between business units and IT department. Thus, the FACTO can also be used together with any other EAF or governance model.

REFERENCES

  • Buckl, S., Ernst, A. M., Matthes, F., Ramacher, M. Schweda., 2009. Using Enterprise Architecture Management Patterns to complement TOGAF. IEEE International Enterprise Distributed Object Computing Conference (EDOC). 
  • Buteau, A., Hardion, V., Le, S., Ounsy, M., Virguier, G., Soleil, Gif-sur-Yvette., 2009. Making Continuos Integration a Reality for Control systems on A Large Scale Basic. Proceedings of ICALEPCS 2009, Kobe.
  • Carrillo,J., Cabrera,A., Román, C., Abad, M., Jaramillo, D.,2010. Roadmap for the implementation of an Enterprise Architecture Framework Oriented to Institutions of Higher Education in Ecuador. 2nd International Conference on Software Technology and Engineering (ICSTE).
  • Cockburn, A., 2011. The Crystal Methods or How to Make a Methodology Fit. http://Alistair.Cockburn.us.
  • Cockburn, A., 2006. Agile Software Development: The Cooperative Game. Agile Software Development Series, 2nd edition, Addison-Wesley Professional.
  • CMMI Product Team., 2006. CMMI for Development, version 1.2. Technical Report.
  • Langenberg, K., Wegmann, A., 2004. Enterprise Architecture: What Aspects is Current Research Targeting?.http://infoscience.epfl.ch/record/52669/files/IC_TECH_REPORT_200477.pdf?version=1.
  • IEEE. (2000) “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”. The Institute of Electrical and Electronics Engineers, ISBN 0-7381-2519-9.
  • OASIS, 2011. Reference Architecture Foundation for Service Oriented Architecture Version 1.0. Committee Specification Draft 03.
  • Odongo, A. O., Sungwon, K., In-Young K.., 2010. A Scheme for Systematically Selecting an Enterprise Architecture Framework. 9th IEEE/ACIS International Conference on Computer and Information Science.
  • Silva, J. B., Saba, H., 2008. Modelagem das Áreas do CMMI de Processo do CMMI usando Business Process Management e Software Process Engineering Metamodel Specification. 34º Congresso Tecnológico InfoBrasil TI e Telecom, Fortaleza.
  • Silva, J. B., 2011. Proposta de Uma Arquitetura para o Gerenciamento de Regras de Negócio em LPS com base na MDA. International Workshop on Metamodels Ontologies and Semantic Technologies, Gramado.
  • Shah, H., Kourdi, M. E.,2007. Frameworks for Enterprise Architecture. IT PRO, IEEE Explorer.
  • Song, H., Song, Y., 2010. Enterprise Architecture Institutionalization and Assessment. 9th IEEE/ACIS International Conference on Computer and Information Science, 2010.
  • Zachman, J. A., 1987. A Framework for Information Systems Architecture. IBM System Journal.

Inscreva-se

Creative Commons 3.0. Tecnologia do Blogger.

Teste a Velocidade da Internet

Siga-me

Curta