IASA

Part II of Able Architecture continues to reveal my vision of Modern Software Architecture.

This is a small book with big ambitions. At only a little over 140 pages it is by EA standards a modest volume. But that shouldn't put you off.

The book presents a surprisingly comprehensive approach to EA with a simple and yet well structured theoretical foundation and enough practical detail to make it credible without overwhelming the novice. Written as a text book for an architectural course it consists of four main sections. These include the usual explanation for why we need EA, updated for the global economy and a little more stakeholder centric than the usual effort. Followed by "positioning EA" which is actually more like defining and describing EA and then two sections on the execution of EA.

One of these is the now a days almost obligatory case study / example, typically the refuge of people who can't actually explain what they mean. My initial reaction was to reach for the phone, order a pizza and turn on the football. But, surprisingly the situation was saved by an example with some real meat.  Not only do the authors demonstrate their points, but they manage to connect them to both their own technique and broader well know concepts like Zachman's framework; all without becoming arcane. In 30 odd pages they deliver more value for the architect than many complete books.

They follow these sections up with a topic that should be getting more air play than it is "The Enterprise Architect". It seems that these days every man and his dog is an architect, frankly I wouldn't feed many of them. But, having said that it's no easy matter deciding what makes an architect. Well, this book has a good go at answering that question and even if you don't agree with the them  there is a certain order and cohesion to their argument that must be respected.

This is a crisp clean work written in "Euro Architecture" style, which is not surprising given its origins. It will work for architects at all levels and will add value to any bookshelf.  Recommended.

Opt'land, Martin, Proper, Erik, Waage, Maarten, Cleo, Jeroen, Steghuis, Claidia ( 2009), "Enterprise Architecture", Springer-Verlag Berlin Heidelberg

ISBN 978-3-540-85232-2

I don't like buying the same thing twice. On first inspection one might think that was what one was doing. This new edition of a book we've already reviewed will look familiar to those who have the previous volume; even the number of pages in each section is similar.

I'm also suspicious of later releases that are substantially bigger than the original work; the previous edition weighs in at 220+ pages while this work has stacked on another 130 pages. Which you would think is a bit of a warning sign, but it wears it surprisingly well. I didn't feel like it was that much of an imposition. In fact, its a feature of the book how already succinct sections have actually been trimmed even further allowing more room for the expansion of the important stuff.

While maintaining the orientation of the original work Grigoriu has addressed the short comings of the previous edition. His framework is now much more securely seated in the foundations of Zachman and Spewak without losing that business process and organizational focus that made the original work  stand out.  Something that's not easy to achieve.

While the book takes a cursory look at the usual framework suspects it does so mainly to establish its own credentials. The bulk of the new material is not surprisingly an elaboration of Function, Flow Layer and Views (FFLV) Framework and the result is coming of age, a framework that can punch it out with the best of them! The bar has been raised and if you're not one of the TOGAF mind slaves the FFLV has to be a serious contender. Accept its business process focus and use something else for the more abstract end of business strategy, but for the mechanics of execution this could be it.

I think it's fair to say that this is the book that Grigoriu always wanted to write and that its production has been a bit of a journey, but the best things always take time. I criticized the previous edition for not being as complete as it should have been, well that's been answered and while nothing is ever perfect I found myself thinking I've got to get a copy of this!

This is not a book for managers. This is a book for architects. It's a good set of alternative views in an alarmingly increasingly monoclonal world. This book will extend most architects' horizons, experienced or novice and is a worthy successor to the previous edition. It's time to upgrade your library. This could be the “little black book of EA”.

Grigoriu, Adrian (2009), An Enterprise Architecture Development Framework 3^rd Edition , Trafford Publishing, Victoria, British Columbia.

ISBN 141208665-5

In the previous post in the series, we have explored the key considerations around the context, objectives and parameters of the SOA governance. This part of the series addresses the key components of SOA governance such as the timing of the governance and the elements which will be governed such as software / services aspects and the hardware / technology aspects which will be deployed during the SOA program implementation.

The timing of SOA governance

Understanding the timing of governance application is key to define the key components of SOA governance. Broadly speaking there are three instances where SOA governance can be applied; during the design time where the services will be identified, modelled and designed; during the development time where the modelled services will be developed and during the run-time or during operations where the developed and tested services are deployed in production. Will every organisation which embarks of SOA program or projects need governance during all three phases? Not necessarily, it depends on the size, scope and complexity of particular SOA program at hand. But the SOA governance mechanism certainly needs to identify and plan ahead for potential implementation around these three phases.

Soft components of governance – models, schemas, services

From the software design perspective the most obvious artefacts which are required to be governed are the business and technical services which are at the heart of any SOA implementation project. But in addition to these, the underlying process models, policies, contracts which bind services together and fundamental message and data schemas may also need to be covered by the SOA governance mechanism. For example; while the deployed services are working well, it may still be necessary to define and manage a formal change and configuration management mechanism around the constituent schemas and process models as very often an organisation would want to introduce new features or changes to deployed services as the business demand changes.

Hard components of governance - Tools and Technologies

There are broadly speaking four categories of tools and technologies which are key components of SOA implementation, First: the registries and repositories which help maintain the library of designed and deployed services. Second: the middleware and/or Enterprise Service Bus (ESB) technologies which help with orchestration of services. Third: the gateway or messaging mechanisms which help communicate with external environments to exchange messages with partners, customers, vendor, suppliers etc. And finally the management and monitoring tools which manages the aspects of service management, metering, performance management and monitoring. The assumption here is that, the infrastructure choices will not be dictated by the tools rather, the organisation’s data center will have these choices made at an enterprise level and the SOA tools will support most standard data center images. The governance activities around the tools and technologies will range from selection of the right tools and technologies, definition of the right-fit reference architecture, modelling for the services on these technologies and the most suitable configuration during development and during the operations.

Next articles in this series will explore the management aspects of the governance such as roles and responsibilities in governance processes, exception management, KPI and success measurement.

There are a number of good posts on EA on YouTube:

http://www.youtube.com/watch?v=HLGyAB0mWAU&feature=related

http://www.youtube.com/watch?v=u-S9KhRQAsg&feature=related

http://www.youtube.com/watch?v=SSkRiLpyrvg&feature=related

"There has never been an Enterprise Architecture manual like this." Proclaims the back cover and I'd have to agree with that. The top one hundred Enterprise Architecture questions answered in 160 pages including the table of contents! With what can only be described as reams of white space.

When you consider that each question is afforded 1.6 pages its really disappointing to find how many answers can only manage one or two sentences on the second page. I really don't know why they bothered including blank pages, there's plenty of space for your notes where the text should be.

Apparently this book is a collection of questions from across forums, education programs and from a consultancy. It's a pity that it not a collection of answers. If you think the big questions of EA can be more than outlined in a page then you're in for a surprise. It ain't that simple! The back cover continues "with tips that have never before been offered in print",  I'd suggest that there might be a good reason for that!

This manual, oh how the word has been devalued, is like a collection of poster notes and about as insightful. If you're looking to impress at a cocktail party buy this book. But, make sure that you have a good escape line because the minute someone serious takes you up you're done.

As deep as a sand bar, a book for fakers and bull shit artists. If I could get my money back I would. In my opinion a cynical exploitation of the EA community.

Blokdijk, Gerard 2008, Enterprise Architecture 100 Success Secrets, No publisher claims this work

ISBN 978-0-9804-8528-8

This book was written by two of the authors of Dynamic Enterprise Architecture (DEA) as a follow on. If you purchased that book then you should probably get a copy of what is practically a companion volume. The book presents a model for accessing how well your EA practice is doing and how to improve those things that need to be. Which are often obvious and devastatingly simple, if we could just see them.

This a typical piece of European EA writing, no nonsense, concise and direct. Designed to be used by those managing EA groups it is obviously best suited to those that have adopted the Dynamic Enterprise Architecture philosophy for whom its straight talking advice will come as no surprise. Even if you haven't heard of DEA, but you are looking to give the old practice a bit of a checkup I'd recommend you take a look at this book. But be warned if you are not a DEA er  it might take a little bit of effort to get your head around their point of view.

What van den Berg and van Steenbergen offer is a two dimensional way of looking at EA that I believe leaves the typical "lets keep doing more of the same only more rigorously" capability maturity models where they belong ... in the gutter. The two vans take Wagter et al's (2005) Quadrant model which classifies EA practices as Isolated, Losing, Barrier, and Enabling and give the reader an objective way of plotting their position on the Quadrant. This won't be easy reading for a lot of practices. However, if you have the courage to do it the rewards are there, because they do have concrete answers to your problems which are clearly the result of experience. No over synthesized symmetrical assessment models for these guys, just an effective tool which sometimes does look a little untidy. But rest assured they do not make things up to balance the model.

This book is 200+ pages of systematic wisdom and is the sort of book a practice should revisit on a regular basis. If you have Dynamic Enterprise Architecture by Wagter et al. (2005) then I'd say that this book is almost a must. If don't, think a little more carefully be for you send your money.

Van Den Berg, Martin and Van Steenbergen, Marlies (2006), Building an Enterprise Architecture Practice, Sogeti, Springer, Dordrecht, The Netherlands.

ISBN 978-4020-5605-5

Background
A few months back (in September 2009 to be precise) I had delivered a webcast / webinar for the community of IASA members. Since then a few members have been contacting me offline with request of further elaboration of some of points which I had listed in the original session. Hence as a follow-up of that session, I am posting key considerations while setting up the SOA Governance mechanism. This is essentially looking at governance from multiple perspectives and is a rather long write-up for one blog post hence I will be posting these in a series of blog posts. Here is the first one of the series which focuses on the context, objectives and parameters of SOA governance.

Understand the Context of SOA Governance
Understanding the context is probably the most important step to follow while starting on the journey of SOA governance. The shape, size and scope of SOA governance effort will depend and should be dictated by the current status, maturity and drivers of the SOA program in place. The understanding of existing business and IT governance processes is also very important as the SOA investments and initiatives will need to have an interlock with existing or planned IT investments, resources, plans and processes. To illustrate this point, if your organisation has already established IT governance models based on industry leading framework such as COBIT , it can easily be extended or adopted to handle the new Services component from the SOA environments.

Define the objectives of SOA Governance
This is probably the fundamental question which the SOA teams and their managers should be answering before they begin any serious piece of work in this space. Why does the organisation need SOA governance? Sometimes its even worth asking the question, “do we need SOA governance?” because SOA governance (or any governance for that matter) comes at an additional cost and overheads. Next key question to raise and answer is “what aspects of SOA are we going to govern?” Design-time artefacts? Run-time artefacts? The processes surrounding them? Also an important thing to note here is that, SOA governance tasks are different than SOA management tasks. For example, policy definition and management are different than policy enforcement.


Define the parameters of Governance
The SOA governance mechanism and associated processes need to take into account various parameters and business compulsions to arrive at appropriate fit. Key considerations in this area are, the organisation design, its geographical footprint, size, prior experience of governance, overall organisational strategy etc. For example, if the organisation is globally distributed and decisions are made at local level then proposing a centrally run and controlled SOA governance model will not work. A more locally driven and collaborative model may be more suitable in this instance. Another set of considerations are the parameters such as budget or financial commitments an organisation can make to SOA governance efforts. The time criticality of business initiatives and hence the agility expected from SOA efforts also need to be taken into account. For example, in long life-cycle companies, more detailed and elaborate SOA governance cycle may make sense but in typical FMCG environment where faster turnarounds is the norm, the SOA governance activities need to be pragmatically defined as well.

In part two of this series, we will focus on other aspects of SOA governance such as actual constituents of the SOA governance, roles and responsibilities in governance processes, exception management, KPI and success measurement.

This NEW brochure describes the value and needs for both messaging and enrichment  capabilities together to have a truly complete ESB solution. Also the business examples in this brochure demonstrate how ESB enrichment capabilities maximize the value and investments to your existing messaging solution. The messaging plus enrichment capabilities in your ESB solution enable fast and flexible application integration, reduce integration costs and bridge to next-generation inter-connectivity.

 Download brochure here

ADT Snippets

The Industry Association of Software Architects conference is set to take place later this month in New York.

As I reported last month, this month's IASA IT Architect Regional Conference is being billed as the largest gathering of IT architects because such luminaries as Grady Booch, Len Bass, John Zachman, Eric Evans, Rob High and Angela Yochem are slated to speak.

According to IASA CEO Paul Preiss, many of these architects have never met each other. But also at the conference, IASA is kicking off a new certification program for IT and software architects.

The new professional CITA program involves intensive training, according to Preiss. "It is a full board examination by a set of peers that actually tests an architect on their ability to deliver against the IASA skills taxonomy," he said. "So it basically says that IASA claims that this person is not only an architect but a good architect."

The report begged the question by Peter Kent, a program manager at G&B Solutions in Reston, VA. "How will the IASA certification be different from FEAC enterprise architecture certification?" he asked.

I ran the question by Preiss, and here's his answer.

• CITA is a multi-level, multi-specialization certification. We have entry level and full professional levels.
• CITA is not related to a particular framework such as TOGAF, FEAF, or DODAF.
• CITA is skill based and therefore focused on delivery underlying all frameworks and implementations.
• CITA is run and delivered by the profession. For a distinction think about the difference (make believe) between the current board certifications for doctors and one run by Pfizer.
• Last but not least, CITA is based on a common distinguishing value proposition for all architects. With both FEAC and ITAC it is difficult to determine what they suggest architecture is, much less why employers should hire them.

It will be interesting to see how many take advantage of  the newCITA program, especially in these tight economic times. Many who are either independent or work for organizations that have slashed their training budgets may have to flip the bill themselves, presuming they feel it will enhance their career prospects.

This book is not so much about EA as about doing EA, or perhaps more accurately about managing doing EA. It's about the processes and governance that surround EA and managing the interface to the business. A topic with surprisingly little good literature. If you are responsible for managing an EA practice or setting one up this book should be on your must have list.

One of the major challenges for enterprise architecture is managing the relationship with the business. On the one hand there is the almost mindless pursuit of short term flexibility and  on the other the architects who struggle to minimize the damage and build universal flexibility on a sustainable foundation.

Most architecture is anticipative, the usual current state, desired state and transition plan approach and while this is all good and sound, frankly its often simply too slow. What Dynamic Enterprise Architecture gives you is options. Options that allow the negotiation of none compliant approaches to solutions. The basic proposition is that sometimes getting a system in is a matter of short term survival and that over rides the anticipative architectural approach. They call this defensive architecture. There is also an offensive version, where the organization has only a narrow window of opportunity. Obviously, in such circumstances the build of a "throw away" system must be at least considered.

Dynamic Enterprise Architecture seeks a balance between agility and coherence through a mechanism called the Strategic Dialogue. This all sounds fine, but here's the catch in the wrong organization I can see Dynamic Enterprise Architecture being touted by the uninitiated in the same way that some promote agile development methodologies. The brutal reality is that in many organizations this is simply the politically correct term for unrealistic expectations and no methodology at all.

The authors provid a set of principles that will guide an organization towards a Dynamic Enterprise Architecture practice and along the way make many pertenant points. In some ways this book is the tactical end of Ross, Weill and Robertson's vision of architecture as strategy. And like RWR they make a number of points about the need for business to mend its ways and get with the program. "Finally business management should recognize that they are restricting business development if they consider IT as a purely supportive process instead of a source of new possibilities." (p. 67) and  "IT and business management determine together which business objectives the organization should pursue." (p. 74). I just know that will not go down well in some places.

This is an excellent book and a fairly easy read at 240+ pages. It should be read principly by executives and chief architects. However, any architect would find it useful. Recommended

Wagter, Roel, van den Berg, Martin, Luijpers, Joost, van Steenbergen, Marlies, (2005), "Dynamic Enterprise Architecture", SOGETI, John Wiley and Sons Inc., Hoboken, New Jersey

ISBN 978-0-471-68272-1

This is an interesting book in a not particularly useful way. Really for C level executives it gives a potted history of the development of architectural frameworks. Given the almost mindless acceptance of TOGAF that seems to be occurring at the moment, I'd suggest that it might be an ideal time to read this book.

The book sets a clear context for EA and spends a few pages, too few on the critical success factors for EA, EA measurement processes and EA program validation. The real contribution however, begins when it addresses the question of creating and choosing a framework.

It lists, explains and describes the underlying principles of the 15 or so frameworks that you are most likely to encounter. I think one could say that it does this in a casual but fairly objective manner, bearing in mind its intended audience. If you are familar with GERA or are intimately familiar with one of the more sophisticated frameworks  then this book will probably be too lightweight for you.

The book also points out a trend, which has been underway for a while, but in my observation still remains largely unnoticed. That is the need for extended frameworks to support the inter organizational collaboration that seems increasingly to be the way in which corporations seek agility.

This is not a book to start your library with, but it can make a contribution to your architectural education. While concise, it could be little better written. I'd suggest a rewrite of the back cover for starters. At around 270 small pages it's the kind of book you can read on the train. It's worth a place on your bookshelf, but only as a lightweight reference.

Schekkerman, Jaap (2006), How to survive in the jungle of Enterprise Architecture Frameworks, 3^rd Edition, Trafford Publishing, Victoria, British Columbia

ISBN 141201607-x

This book can only be described as a titanic effort. Designed as a source book for architects working in the US defense industry this epic consists of three volumes, Process and Products, Data-Centric Architecture and a volume on Architecture Based Assessments to Support Capabilities Acquisitions. By my calculation these volumes contain over 1870 pages.

If you work in defence then I'd recommend you get a copy, if you don't then I wouldn't be in a hurry to add a copy to your collection, borrow a friend's. While the books are clearly written with the defence industry in mind the techniques and tools have a wider application and the origin of the book should not preclude none defence architects from having a look at it.

These volumes contain useful sections on planning, governance, training and architectural integration and validation. The size of the work allows a completeness that few other works manage to achieve. While it's written in plain english with complete sets of instructions and lists of deliverables; it contains arconyms and concepts that the unintiated will not be familiar with.

These are specialist works for defense architects, not for the manager or the novice and probably not for most none defense architects. But, not without considerable merit. Mr Babers is to be applauded for his tenacity.

Babers, Charles, (2006),”The Enterprise Architecture Sourcebook”, Charles Babers, El Paso, Texas, vol.1 – 3.

ISBN 978-1-84728-925-4

In some ways this book is sort of a soft sciences version of of Bernus et al. Handbook on Enterprise Architecture. Saha presents us with  twenty six case studies organized in five sections. These are Frameworks and Methodologies, Governance and Management, Transformation and Value Realization, Implementation and Deployment and Technology and Service-Orientated Architecture.

Each section contains a number of chapters written by experienced architects, this is very much Enterprise Systems Architecture in Practice, any reference to theory is typically couched in a practical context thus bridging a gap that many publications fail. This book is the collective knowledge of a lot of talented people and contains a lot of thought provoking points and painful experiences.

This is not a book to start your collection with and its probably not a book for the manager or the novice, but it is none the less an excellent book that delivers. Well written, but not overly academic this is a big book of 460+ pages of carefully selected quality EA writing, beautifully presented. There really isn't much else to say about it. I'd suggest that it is destined to become a classic.

Saha, Pallab (ed) (2007), Handbook of Enterprise Systems Architecture in Practice, Information Science Reference, Idea Group Inc, Hershey.

ISBN 978-159904189-6

In my never-ending quest to understand this profession I am consistently amazed at the differences between types of practitioners. Most of my early focus was on the different 'perspectives' on how architecture is practiced based on how it was defined by individuals (engineering, development, communication, business, value, etc).

Im becoming even more curious now about how it is shaped culturally. What is the difference between a UK, Swedish, US, and Malaysian architect. Is it influenced by culture, GDP, outsourcing status, industrialization, etc.

So, finally, to my question. What do you think, if anything, is different about architects in the your country? Im more interested in the people, but if you want to discuss what is different about architecture in the UK that is good too.

I have obviously been working closely with our Asia-Pac group for some time and am very proud to see the significant success of our chapters in Indonesia, Malaysia and Singapore. What is even more interesting is the success and opportunity we see in growing the next international set of thoguht leaders and speakers.These are just a few highlighted speakers from the upcoming events.

There were a number of facets to this article I found interesting. First was the legal teams interest in what type of information is available on company systems. I have always thought that law and especially areas of social identity blurring with professional identity are going to be a major issue for us in the future. The anecdote about the employee profile interested in fly swatting and skinny dipping are relatively mundane versions of this. But what happens when a big sale depends on a few employees and their social profiles are embarrising in some way? Are we going to have a mega social identity site like facebook and linkedin sued? What do the architects do about this. Meskell's architectural value model puts 'customer value' 2nd right after fiscal value. Most architects only focus on the fiscal value component (ie x new technology will make us x new dollars). What happens though when technology becomes a major factor impacting all areas? How do we get our stakeholders to understand the potential impacts?

Posted by Thomas Claburn, Nov 3, 2009 06:36 PM

In a moderated discussion at the Enterprise 2.0 Conference in San Francisco on Tuesday, Booz Allen Hamilton VP Art Fritzson and senior associate Walton Smith shared their experiences integrating social and collaborative software into their consulting business. Read more.

This is another one of those methodology born of experience books. Predominately practically orientated, if it does have an underlying philosophy it is start simple and stay simple. The book has an entire chapter dedicated to spelling out its philosophy which as one might guess it all about being simple and consumable. According to LEA complexity is the root of all  IT evils. LEA makes no excuses or grand claims it is not, in its own words a pristine architecture or a business strategy.

This is a surprisingly comprehensive work given its size 300+ pages and that includes about 100 pages of reference material that basically describes the LEA artifacts. There is also a very good chapter on Dysfunctional Enterprise Architectures.

LEA divides architecture into three broad domains Strategic Architecture which engages the business leadership, Conceptual Architecture which develops the road maps and Execution Architecture which guides the projects that implement the architecture.

LEA is careful to define the architect's role in each of the three architectural domains. An important point that many authors fail to recognize or elaborate on. And while careful consideration is given to the SDLC; LEA is not as obsessed with it as McGovern and company.

This approach gives LEA a scope considerably broader than many similar practical methodologies. While I'm not sure how well LEA would ultimately scale its emphasis on the strategic perhaps makes it a better fit for organizations that have already grasped the importance of the enterprise part of EA. This is not the sort of  methodology that you could  sneak in through the back project.

This is not a manager's book and its not a novice's book, if you are starting an EA practice in a small to medium size organization you could do a lot worse than use this. The most surprising thing about this book is that more people haven't read it.

Theuerkon, Fenix (2005), Lightweight Enterprise Architecture, Auerbach Publications, Taylor & Francis Group, Boca Raton.

ISBN 0-8493-2114-X