Updated SOA and User Interface Services Paper Available Now
I have just added an updated version of my paper on SOA and User Interface Services to “My Papers” page on my Blog.
Aggregated enterprise architecture wisdom
I have just added an updated version of my paper on SOA and User Interface Services to “My Papers” page on my Blog.
Architecture maturity assessments help to determine how companies can maximise competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management.
There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the US Department of Commerce ACMM, the Open Group architecture maturity model, and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.
As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).
Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.
Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.
In the following example you may observe four different phases on how to run an assessment.
The Phase 1 would include several steps:
Sources
o CMMI for Development (Version 1.2, 2006)
o Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
o The US Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
o TOGAF® 9.1
o NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)
We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).
The use of radar may also be a nice way to present the results. (Example below)
The Phase 2 would include several steps:
The updated report may then look like this (extract of an example):
The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.
To conduct an evaluation of an organization’s current practices against an architecture capability maturity assessment model, allows to determine the level at which the organization currently stands. It will indicate the organisation’s maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.
In my previous research, I have investigated the relationship between transformation, planning, and communication in large-scale architecture programs. Obviously and unsurprisingly, communication has a huge impact on the perception and relative success of enterprise architecture and change management initiatives. The important turning point, that I have argued so far, is the way communication shapes and is shaped by the organisational systems in which it takes place. The German sociologists Dirk Baecker and Niklas Luhmann have been my primary sources of inspiration and research for formulating a set of guiding principles for change programs that do not simply assume that communication is a fully informed and unambiguous process of sending and receiving objectified information. Organisations and their people are all systems in which communication takes place. The boundaries, values, and cognitive processes of each system influence and complicate the practice of communication, which, in turn, requires a complex systems model to model and explain its behaviour.
So what is the alternative? The obvious choice is to integrate communication as a core concept and layer in enterprise architecture itself – the communication architecture. Here, communication refers mainly to the social processes of human and computer interaction and – not pure computer networks or algorithmic manipulation of signals. On the other hand, communication is not only about people and utterances – computers and technology play a vital role as well as an efficient transport medium. My point is that communication in itself is a socio-technical system describing the complex message exchange between humans, intentions, and machines – or, in C. S. Peirce’s words, a semiotic system. Semiotic systems have dissipative structures of signs in networks constituted equally by humans and machines. Communication in enterprises can be interpreted as complex signs, manifested in dialogues, written emails, and network packets in the router. Some communications are relatively stable (a published document or a sequence of bytes representing an email) whereas others are fragile and chaotic (human intentions, political agendas, gossip by the water cooler). Their manifestations are entirely different, but the purpose remains the same: exchanging ideas, values, and intentions – utterances – between people in- and outside the enterprise in order to ensure its long-term survival. As I havepreviously pointed out in this blog, enterprises as socio-communicative systems have rhizomatic properties – the modern enterprise should not be solely viewed as a hierarchy of processes, layers, and computers, but also as a constantly transforming multiplicity of events and signs. Thus, the theoretical foundation for describing the communication architecture of the modern enterprise must be found within the theory of organisational semiotics and sign theory.
In upcoming blog posts I will attempt to tie these very theoretical reflections back into a practicable architecture framework for organisational communication.
I have added another paper to my list of papers. This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…
I have added another paper to my list of papers. This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…
I have added another paper to my list of papers. This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…
I added a new page (above and to the right). It contains links to some of my papers. I will be posting more from time to time. I am ordering the papers so that the readers might be better able to follow my discussion in each. I hope that helps. Let me know with comments, what you think.
Bob
The Papers include:
1. Enterprise Portfolio Management and Enterprise Architecture
Coming shortly
2. The Role and Development of an Enterprise Architect: A Devil Advocate’s Perspective
3. Systems Engineering and System Architecture in an Agile and Short-cycle Transformation Environment
I added a new page (above and to the right). It contains links to some of my papers. I will be posting more from time to time. I am ordering the papers so that the readers might be better able to follow my discussion in each. I …
I added a new page (above and to the right). It contains links to some of my papers. I will be posting more from time to time. I am ordering the papers so that the readers might be better able to follow my discussion in each. I …
Seemingly a lifetime ago (2009!), I shared how security concerns have to be “baked into” any cloud platform, as well as a simple set of capabilities to consider when addressing said security concerns. Of course, information security is just one a…
It’s been 9 months since our last post. That doesn’t mean that we’re no longer here, or that we’re not thinking about these topics, or that we don’t have anything more to say – those of you who know me realize that option is just about impossible…
Framework-ism: Form and structure over content and good practice (not best practice). Best practice is all too often a cover for theoretically ideal, but practically non-functional solutions.
Boil-the-ocean-ism: All too generic frameworks intended for large-scale program transformation lack local focus and technical guidance.
Architecture astronaut-ism: Abstraction upon abstraction upon abstraction until everything is so conceptual that end-users have dissolved into TOGAF deliverables.
My mantra for solution architecture governance is: