At this risk of sounding like a management, motivational speaker there is one consistent piece of advice that I give to IT organizations over and over and over again when undertaking large initiatives: start small and build in incremental steps.  This is particularly true for Enterprise Architecture groups.  It is in this spirit that I recommend the adoption of agile methods within the Enterprise Architecture groups, even if agile is not used within the application development groups of the organization.

Agile methods can be successfully applied to all sorts of Enterprise Architecture activities, but to illustrate its applicability let’s look at how agile applies to the development of a standard technology platform for application development.  What I mean by a technology platform is a set of standard technology components and reference architectures that can be used by application development projects within the organization, such as a platform for e-commerce applications, or a platform for Java-based, web development, etc.

While we’re on the subject of using agile development, I’ll also cover what considerations one might take into account while defining a technology platform to maximize the benefits of agile methods in application development.

First let me level-set with quick a definition of agile.

The definition I use is made up of eight simple ideas:

1. Small release and rapid feedback cycle – By moving stuff into production use as quickly as possible you start to realize benefits quicker and you get feedback sooner.  Most importantly you don’t wait until months have passed to realize the project is failing.
2. Don’t be afraid to change the requirements – As you put releases out and get feedback, you’ll refine your understanding of what the customer wants and the customer will refine their understanding of what is required.  This can be a good thing, embrace it.
3. Continuous customer interaction – By keeping the customer involved you allow for that rapid feedback.
4. Define releases based on a functionally complete set of features - Each release should demonstrate a function of the complete system from the perspective of the customer.  I.e. the customer should be able to look at the release and test it against their expectations without someone explaining why this or that doesn’t work yet.  This goes against a lot of old school engineering practices that say build your entire infrastructure first and then build the functionality.  The reality is sometimes we build infrastructure that we never use.  A corollary to this is that before we start building we should know how to test, so when the customer defines the requirement we need to also define a test case.
5. Don’t be afraid to refactor – One of the reasons we tend to build out infrastructure before functionality is because we like to write a piece if code, test it, call it done, lock it away in a source control system and don’t change it again.  This works fine if you follow the approach of build all the infrastructure first and then the functionality and you don’t change any of the requirements mid-stream.  Since we’ve already accepted the fact that requirements will change and we’re not building out infrastructure until we need it we have to be flexible and allow for the refactoring of code that was already released.
6. Automate testing as much as possible – The main reason we fear refactoring is we’re afraid we might break something by mistake.  The solution: automated regression testing.   If it’s easy to test if broke something you’ll be more confident in your refactoring.
7. Continuous integration – Since most projects have multiple developers and we’re allowing them to refactor code as required we need to synchronize as often as possible.  Practically this means a shared environment with all the automated build and test capabilities.  Ideally the integration build and test process should be push button.
8. Keep it simple – Underlying everything in agile is the basic belief that the simplest solution is the best.  Don’t implement a general purpose spreadsheet if all you need is the ability to sum a column of numbers.  Don’t build out infrastructure if you don’t need it.  Don’t design complete abstractions when a simple abstraction will do.  Don’t write hooks for 15 features you haven’t thought of yet into something. Etc.

So let’s look at how each of these ideas can be applied to defining a platform:

Small releases and rapid feedback – I always recommend to organizations starting to defined standards to start slow.  Don’t define more standards than the organization needs, has the ability to absorb or has the ability to support.

• If you have only one application that uses a rules engine in your entire portfolio, there’s no sense defining a standard around rules engines and certainly no sense is holding up the development of a reference architecture until you’ve figured out how to incorporate the rules engine into it.
• Organizations absorb standards by writing new applications that use them, if there aren’t any applications in the pipe for development to use a standard it won’t get used and by the time it does it might be out of date.
• If you tell someone they have to use AJAX you also need to tell them how to use AJAX.  If you don’t have the bandwidth to provide the support to a standard think twice about defining it.

As you put out standards see how they are used and get feedback from actual application developers.  If they are also using agile methods you shouldn’t have to wait long for feedback.

Changing Requirements – Platforms change whether we want them to or not: technology evolves, vendors update their software, and new applications have new requirements.  No matter what methodology you use for platform development you have to plan for change.  This is often called the “technology adoption lifecycle” every company that is serious about managing standards has some version of it.

Continuous customer interaction – This should be even easier for platform development than application development since the customers are members of IT who speak the same language as the platform developers.  There’s little reason why platform development should not be getting constant input from the application development community.

Functionally complete feature sets – A platform is essentially infrastructure so defining a functionally complete feature set is probably something a platform developer will have an easier time of than an application developer.  A platform should address specific needs of the application development, maintenance and operations.  Some thought should be put into what those needs are and what the minimum feature set required to develop those releases are.  One complication for platforms is that often times they are build on vendor products which have lots of features you don’t really need.  Part of defining a platform is setting the rules around which features of a vendors product should be encouraged, which ones allowed and which ones discouraged or even banned.  This is something that is often missed in platform development; the results are applications that are irrevocably tied to a specific vendor’s product.

Refactoring – Not that I want to discourage the use of refactoring, but a word of caution here is prudent.  Good platforms are designed to be modular with well defined interfaces between the modules and most important clean Application Programmer Interfaces (API) exposed for the developer using the platform.  When refactoring within a platform it is ok to change the interfaces between modules in the platform, but be very judicious when changing the externally exposed APIs.

Automated testing – This is just good practice, I don’t care what you’re developing.  And the infrastructure guys will love you if you develop an automated test for validating a deployed platform.

Continuous integration – Another good practice, and again the infrastructure guys will take whatever assistance they can get in automating the deployment of a platform.

Keep it simple – There’s an old saying about the US Supreme Court that says the court can withstand anything except ridicule.  Basically it means that if the court makes decisions and nobody follows them, they become meaningless.   As a result the court tends to look for the simplest way to resolve any issue figuring that it will also be the most readily accepted by all parties.  The same is true of platform developers.  If no one uses the platform it becomes meaningless, thus a good platform is both modular and minimalist, thus allowing for piecemeal adoption as an alternative to wholesale rejection.

As promised, while we’re on the subject let’s look at how a standardized technology platform can support agile application development.

Small releases and rapid feedback – Part of a platform definition should include the release mechanism.  If releasing a new application onto a platform is a four week task, then the idea of small, rapid releases will not be very efficient.  The platform should be designed to allow for releases as quickly and effortlessly as possible.

Changing Requirements – One of the most contentious parts of any application development project is defining non-functional requirements (NFR).  Project shouldn’t be focusing on NFRs that much in the first place; most NFR should already be defined at the enterprise-level (i.e. availability, security, monitoring, etc.).  By building enterprise-level NFR compliance into the platform, the application development team can focus on functional requirements.

Continuous customer interaction – The platform needs to support development.   The development group shouldn’t have to figure out how to make a “beta” version of the application available to the customer, the platform should have that mechanism already.

Functionally complete feature sets – This is one of the fundamental reasons why we build platforms.  A lot of the infrastructure issues will be common across applications and to the extent that the platform is complete out of the box the application developers can jump straight into functionality development knowing all the basic infrastructure is there already.

Refactoring – If the platform is modular it will support refactoring the application in smaller increments.  Often times the scope of a given increment will be influenced by the scope of the modules within the underlying platform.

Automated testing – The platform can do a lot to support automated testing; this should be included as a requirement in the platform development.  Also, there should be a simple way to validate a platform has not been corrupted as well as mechanisms to support the regression testing of an application when the underlying platform changes.  How many times do we defer taking vendor updates because we’re afraid it’ll break something?

Continuous integration – Again the platform can do a lot to support continuous integration.  Most immediately if the platform can easily be virtualized that solves a host of resource issues.  Also, the easier it is to deploy the platform the easier it is to refresh our environment if we’re afraid we corrupted something during testing.

Keep it simple – Developers are assumed to have a certain base knowledge set, but they’ll need to learn a few things about the platform if it’s the first time they use it or if it’s been updated.  The platform developer should try to minimize this learning curve.  It’s just good practice.

A final word about the adoption of agile for Enterprise Architecture work, this one’s for the finance guys.  One complaint about agile application development is that it doesn’t fit well within generally accepted practices for deciding when it is acceptable to capitalize application development and when to treat it as an expense.  To make matter worse the general practice is: when in doubt treat it as an expense.  Unfortunately this has the result that when comparing agile to waterfall, agile looks less attractive from a financial perspective.  Fortunately since Enterprise Architecture work is treated an expense in most cases anyway, this isn’t really a problem.  In fact, agile’s focus on small releases, put into production quickly will allow your EA effort to deliver return on investment more quickly; that’s always a good thing.

In the recent Garner report “Ten Criteria for Choosing an External Service Provider for Your EA Effort", 3 of the 10 criteria related directly to the architects from the External Service Provider (ESP):

6.5 Does the ESP Have a Standard Approach for Identifying and Developing Architects Within Its Pool of Consultants?

6.6 Does the ESP Have a Standard Way of Describing Architects' Levels of Competence?

6.7 Does the ESP Have a Consistent Way of Staffing the Right Architect With the Right Skills on the Right Project?

Gartner is quite right to include these in their criteria.  No issue has nagged the Architecture profession in general and the Enterprise Architecture discipline in particular as the challenge of identifying and developing architects.

I’ve often said that we play a cruel joke on most architects at some point in their career.  Since most architects start as developers they spend years learning to take large problems and efficiently break them down into smaller and smaller pieces until finally they get to a level of detail that they can readily translate into code.  Then after having proved their analysis skills sufficiently they are promoted to architect and told to do everything they used to do except backwards.

The programmer’s skill is analysis, but the core architect’s skill is synthesis.  This is not to say that architecture doesn’t require a great deal of analysis, but the critical step in architecture is often re-assembling the pieces into new higher-level constructs in order to get to that which is “architecturally significant”.  This is synthesis.

In his book “A Whole New Mind: Why Right Brainers will Rule the Future” Daniel Pink points out that analysis is a left-brain-directed skill, but synthesis is a right-brain-directed skill.

(This is an EA blog and not a neuroscience blog, so if you want to understand all the differences between the left-brain and the right-brain I suggest reading “A Whole New Mind”, but suffice it to say that the left-brain is sequential and logical, but the right-brain is holistic or non-sequential and intuitive.)

Diving deeper into “A Whole New Mind”, Mr. Pink describes six essential “senses”, as he calls them, which are all right-brain-directed aptitudes.  He argues that these senses complement our left-brain-directed reasoning and are essential to success in the new “conceptual era” that we now find ourselves entering.

Whereas he describes the value of these senses in a generic context, I’ll describe their value to the architect.

1. Design – In order for a system to be successful it must first of all be usable and second of all it must be used.  A system that merely delivers function may not meet either of these criteria.  Particularly when implementing a system that changes the way people work, it is important to design a system that compels the user to explore the new functionality and incorporate it into their normal way of working.  One could argue the Blackberry and the iPhone have very similar functionality, but whereas as the Blackberry took nearly a decade to become ubiquitous, the iPhone achieved the same within its first year.  Why?  Design.
2. Story – Architects often have the skill of being able to hold an enormous amount of complexity in their heads at one time, but the successful architect can convey this complexity to others in a way that is simple.  The unsuccessful architects is often frustrated by the fact that their audience cannot appreciate or even understand the elegant models they develop to manage complexity no matter how many times they take them through the details.  But the successful architect uses metaphor and story to convey their message.
3. Symphony – Can anyone doubt that architects must be big picture thinkers?  The sense of symphony is to see the whole composition, to understand how a change in each component will affect the whole.
4. Empathy – As any fan of Star Trek knows, humans are not known for being logical.  An architect’s ability to really put himself/herself in the shoes of the user is enormously important.  This ability is a form of empathy, feeling with the user not just feeling for the user.
5. Play – The notion of play has lost much of its frivolous taboo in recent years.  Much research points to the effectiveness of games at teaching problem solving skills.  In some case games can themselves be used as problem solving techniques.  And last but certainly not least, the value of “fun” has been shown to be significant in boosting productivity, facilitating adoption of new ideas and ways of working, and even enhancing the retention of knowledge.  When the LoJack system was first deployed one factor leading to its adoption was that police officer found it fun to use the system; tracking down a stolen car took on a video game-like quality and thus the police embraced it whole heartedly.  An Architect should be able to incorporate the right mix of seriousness and play in the systems he/she designs.
6. Meaning – Although the current “Great Recession” has caused many people and corporations to focus more on survival, this will likely prove to be a minor blip in a trend that has seen the developed world search out for meaning in life as it feels more and more comfortable that its basic material needs will be met.  This applies to both individuals as well as corporations; how many corporations today have adopted corporate value statements that include the responsibility of the corporation to society as a whole.  Enterprise Architects are well position to help balance the fiduciary responsibility of a corporation to its shareholder with these socially-conscious corporate value statements.

All this might lead one to conclude what many have always feared, that architects cannot be grown; they must be found.  Fortunately as Mr. Pink points out one can develop their right-brain skills just as we have learned to develop our left-brain skills.  He offers exercises for developing the six senses in his book.

So I believe architects can be grown, but to do so requires a program that develops both left-brain and right-brain skills.  And whereas experience does count for a lot in the discipline of architecture, I’m not so convinced that the experience one acquires from years of being a developer or a project manager is what one needs to be a good architect.

It is my hope that the architect profession evolves to the point where architect training starts much earlier in the career of individuals.  In fact I would hope (and I believe there are schools working on this) that architecture evolves to the point where colleges and universities offer IT and Enterprise Architecture degrees just as they offer building architecture degrees.  And these degrees will develop both left-brain and right-brain skills just as current day design school do.

1. What is the cost that your organization is paying for your constraints? - constraints could be your service levels in terms of response time, could be quality, could be ability to resolve business challenges. Most important thing is that you as IT organization, are you aware of cost that business pays for every constraint that you bring on the table? You may not be watching but trust me, one who is paying the cheque for your services is watching it. Check it out.
2. Given a chance of better ‘service provider’ today, will Business owners replace you? - Don't get surprised. Many organizations treat their internal IT organization as yet another IT services provides and pretty much deal with them like one. Organizations have kind of got into mindset of looking for better options if their internal IT organization is not able to perform upto the mark. Options are always there, its just matter of making the decision. Its all going to be 'business value' game and every one will have to earn the cheque through business value delivery and not just by 'doing things'. Serious stuff, I think.
3. Will you remain relevant ‘tomorrow’ with changing patterns of technology evolution? - Changes are happening rapidly and some of them will change the game for businesses. Linking back to previous point, you as service organization, how much are you ready to enable your businesses to leverage the new technologies without reading putting much to stake in terms of risk? If you do not evolve, new technologies will make you irrelevant in terms of your servicing capabilities and point# 2 will make it even more serious.
4. Are you busy solving your internal problems or are you solving business problems? - Watch out where are the leaders and managers of your IT organizations spending their time on. If they are busy sorting out their internal issues and not really providing leadership in resolving business challenges through IT capabilities, there is lot of wastage happening. Its not more affordable.
5. How much can your business organization rely on you for their future bets? - Probably THE most crucial question that IT organizations need to think of. Can their businesses rely on them to capably provide support for the future business bets of the organization? Businesses are in transition and hence no one really knows how things are going to be turned out in future. But they are picking up their best bets and playing on it. If IT organizations are not able to support the future bets, that's lot to lose, big stake. So first, as IT organization, are you aware what those big business bets are for your organization and secondly, are you ready to make those bets happen from your end?

Is this scary? It should be. But again, its meant to show the good news also. While it is scary, it also means that current way of doing is not going to sustain so you have option to change the game. That's exciting part of it. You get to be part of the change and not just being part of the change but leading the change. Can you ask for more?

Information in SOA world is often considered only within the context of specific services and processes whilst the most awaited gains and benefits of SOA investment is business information availability throughout the organization and to its partners and regulators. When an organization embarks on SOA and integrates its internal systems across LOB’s it will soon discover that there are inconsistencies in its information that was not visible before as it was hidden within various silo applications and data sources.

Yesterday I had jury duty; one of only two civic duties enumerated in the US Constitution – the other being voting (ok paying taxes might count as three, but let’s not go there).  Anyway, several hours of sitting in a court house did get me thinking about the “rules of evidence” for architecture.

A common pitfall that IT organizations fall into when trying to formalize the practice of architecture is to setup an architecture review broad (ARB) without proper foundation; specifically without setting down the rules of evidence for architecture.  In ancient times the village elders or some monarch dispensed justice without formal legal structure, but I’ve yet to see an ARB that wielded this kind of absolute authority over IT projects.

So just as modern courts are governed by rules of evidence, the ARB must define what is to be presented as part of an architecture review and what criteria is to be used to judge the fitness of what’s presented.  TOGAF™ provides a succinct description of the function of an “Architecture Board” without trying to define any strict formula for an ARB to follow.  Nor will I try.  Instead I’ll just focus on some of the basics.

A common ARB function is to ensure conformance to standards.  If the organization has not defined any standards or has failed to define standards that are relevant to the projects that the ARB will review, then this part of the review becomes little more than a debate between architects.  It may be a debate in good faith, but that’s called a design review and whereas I’m all in favor of architects reviewing each other work and giving feedback, this process generally lacks the kind of demonstrable benefits that are required to justify anything beyond the most cursory investment of resources in the ARB.

I mentioned the importance of standards being relevant.  Standards are defined because they either solve a common problem, thus saving time and resources from having to solve the same problem over and over again, or they support some other architectural objective such as security or ease of integration.  If one can’t demonstrate how either of these is the case for a project under review, then the standard is not relevant and enforcing conformance becomes a challenge.

When deciding where to start with defining standards it’s a good idea to look in three areas:

1. Look at what is in common use in the organization today.  This represents a set of successfully applied solutions to a set of known problems.  It also represents technology that is already familiar to the organization and skills sets that are already available.
2. Look at the pipeline of projects in development or under consideration.  This represents a set of problems that will need to be solved in the near future, but be sure to look for common problems, not simply interesting ones or even the hard ones.
3. Look at known architecture priorities of the organization.  E.g. improving security, enhanced analytics capabilities, or improved integration between systems.

Architecture Artifacts

A well defined set of standards is not the only requirement for a successful ARB.  Defining what has to be brought into the review is also important.  Besides allowing the project team to appropriately prepare for an architecture review it also ensures that the ARB get’s a complete and accurate picture of the project under review and solutions being proposed.

For many a project teams, an architecture review is nothing more than a hurdle to be passed with as little delay or disruption to the project plan as possible.  Thus the project team is often incentivized to game the review process, not to embrace it.  Gaming the review process is usually just a matter of presenting those aspects of the project that are most well understood and avoiding those areas that are less understood when presenting the project to the ARB.  This is only possible when the material to be presented is left up to the discretion of the project team.

Defining what architecture artifacts should be brought into a review should be based on the artifacts that are already being created as a part of the project.  The challenge here is that many an organization lacks a really well defined architecture methodology that all projects follow.  Exactly what type of artifacts should be a part of a project architecture methodology, I’ll leave for another (much longer) posting.  The key is that when defining the artifacts that should be created as part of the project and brought into the architecture review one should keep in mind what information about what aspect of the project or the proposed solution each artifacts is communicating and how each artifacts is used in future steps in the process.

Scope

The scope of the architecture review also needs to be defined.  Is it just about application architect? Does it cover data and information architecture?  Does it cover infrastructure?  For whatever scope is defined for the ARB, the appropriate standards and artifacts need to be defined.  Also the ARB needs to include subject matter experts across the full scope of the ARB.

Many organizations divide the architecture review process across multiple boards.  This separation of concerns can be useful in ensuring that each area of concern is fully addressed, but it can also provide an additional burden for the project team to have to prepare multiple reviews.  When choosing to separate concerns it is still important to have some coordinating function to ensure that all the appropriate concerns are addressed; this is often delegated to whatever general project governance process exists.

Outcomes

Justice Potter Stewart said that he couldn’t define pornography, but “I know it when I see it”.  I often feel the same about the term “enterprise transformation”.  Not that there haven’t been many attempts at defining transformation; I just feel that most fall short of addressing the vernacular use of the word.  Particular they don’t address just what is it about transformational projects that make them harder than any other large project.  Nor do they help identify when “transformation” is required.

So let me posit a different term: inertia.  Often when we use the term “transformation” what we are really talking about is significant or sudden change in inertia.  Consequently the role of Enterprise Architecture can be defined in terms of how it is used to manage inertia in an enterprise.

Enterprises develop inertia over time.  And just as inertia keeps a gyroscope from changing direction, inertia stops enterprises from changing themselves.  Transformation is about overcoming inertia to change direction.

Inertia is not always a bad thing.  Inertia can be very valuable in keeping an enterprise on track. When we talk about institutionalizing change we are talking about creating inertia that will keep the enterprise from reverting back to its old ways.  In this case inertia is the gyroscope that keeps the organization moving in the right direction.  It guides future decisions as processes and systems are updated.

Thus not all change is a change in direction.  Some change may be a course correction or a detour around a temporary obstacle.  Some change may be simply to keep going the same way but more efficiently or faster.  These changes may nor require a change in inertia at all, or may require only minor changes in inertia.

However, when a change in direction is significant or sudden inertia will become a major obstacle to change.  This requires an effort of Herculean proportions; this requires transformation.

Types of Bad Inertia

• Organizational Inertia – This is about people resisting change.
• Managers and executives resist change when they fear they will lose power because of it.
• Employees resist change when they fear they will lose their job because of it.
• But mostly people fear change because they lack confidence in the portability of their existing skill set and their own ability to adapt or learn new skills
• Financial Inertia – This is about the cost of change. Pre-existing investments in capital and resources make change expensive:
• We just built that factory last year.
• We just implementation that system.
• We’re still depreciating that expense.
• Process Inertia - The “we always do it that way” syndrome.
• System Inertia - We do it that way because that the only way the system supports and the system is too hard to change.

Strategy Sets the Course, Execution is the Journey

When we talk about direction for an enterprise we are talking about strategy.  Strategy does not simply specify a straight line direction; strategy defines a course from where we currently are to where we want to go.

Execution is how we translate strategy into action.  When strategy and execution are aligned the enterprise moves smoothly along the course laid out in the strategy.  Over time strategy changes and execution must change with it, but if inertia has built up and is not properly accounted for strategy and execution can drift out of alignment.  The problem is not that we don’t know we need to change direction; the problem is we can’t change direction as easily as expected.

Take the example of a car driving on an icy road.  If the road suddenly curves the driver will see it and know that he/she must change direction to match the curve.  So he/she turns the wheel of the car, but the ice on the road has robbed the tires of the traction required to execute that turn; the car continues to go straight.  The driver continues to turn the wheel for the expectation is that turning the wheel will cause the car to turn.  Finally the tires may summon enough traction to execute a turn, but at this point the driver may have over turned the wheel and the car turns more than required.  Anyone who has lived and driven in a cold winter climate knows how this story ends.

Unfortunately unlike the driver of the car on the icy road, it is not as easy to recognize when the enterprise has failed to change direction as desired.  Often times the enterprise fails to respond to even what are considered minor changes in strategy. This failure to respond may go unnoticed as may the next change in strategy and the next.  Left unattended the misalignment between strategy and execution grows over time.  Worse yet as execution deviates from strategy making strategy changes become harder because the assumed starting point may not be correct.

Back to the analogy of the car on the icy road; since the normal feedback associated with turning the wheel is not available, the driver turns the wheel randomly until he/she is no longer certain in which direction the wheels are pointing.  This is an enterprise skidding out of control.

The Role of EA in Avoiding the Car Wreck

It’s popular to talk about Enterprise Architecture as aligning business and IT.  Like “transformation” that has always struck me as too vague.  I prefer to talk about EA as aligning execution to strategy.

So if we define transformation either in terms of change to strategy or re-alignment of execution to strategy, the role of EA in transformation becomes one or more of the following:

1. Avoiding misalignment of strategy and architecture in the first place.
2. Recognizing when there is misalignment between strategy and architecture.
3. Identifying specific misalignment between execution and strategy.
4. Root cause analysis in the misalignment of execution and strategy.
5. Designing new modes of execution that align with strategy.
6. Identifying and minimizing the potential for creating bad inertia in the execution of strategy, in particular avoiding System Inertia, one of the most common and troublesome forms of inertia.

In the following, I try to evaluate the semantic dimensions of “architecture” compounds – as a framework for structuring discussions, and facilitating communication. Subsequent postings will evaluate divergent interpretations of terms commonly used in the context of enterprise architecture, and provide recommendations how to handle these interpretations in interactions between architects.

Please contribute your own views on how the word architecture is used. It will be extremely interesting to gather additional aspects of the term.

Kind Regards

Thomas Obitz - Principal Architect

Composing “Architecture”

Within the IT community, the term “architecture” traditionally is used in one of three ways: One is as a characterization of an object (the “architecture” of a cathedral), the second is to describe the process of designing these architectures[2].  The third meaning – the profession of the architect – today is derived from the second[3].

In the characterizing context, an XYZ architecture can be (without claiming completeness)
·         the architecture of an XYZ (Enterprise Architecture - Architecture of an Enterprise)
·         an architecture for an XYZ (Enterprise Architecture - Architecture for an Enterprise)
·         an architecture describing the XYZ aspects of something (Information Architecture - Architecture describing the information assets of an Enterprise)
·         an architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (Information System Architecture)
·         an architecture consisting of XYZs (Process Architecture - Architectural description consisting of process models)
·         an architecture in the state XYZ (Target Architecture)
As an art, we find “XYZ architecture” as
·         architecture using an XYZ approach (Enterprise Architecture – doing architecture using Enterprise Architectual approaches, even for a smaller unit than an enterprise, or for a government)

Architecture of an XYZ (constitutional)

 ISO 1471 talks about the “architecture of software intensive systems”, which was usually abreviated into “software architecture”. This straightforward interpretation has been transferred to the field of Enterprise Architecture only recently. The “Architecture of an Enterprise” therefore may describe the relevant aspects of an enterprise, the way an organization is structured, how its departments interact, and how they generate value.

Architecture for an XYZ (demarcational)

 The terms “Enterprise Architecture”, “Departmental Architecture” or “Line of Business Architecture” can be used to describe the scope an architecture is relevant to. An “industry architecture” is an architecture not of, but relevant to a specific industry. If used in this way, “Enterprise Architecture” does not explain what aspects it describes, but just that it applies to the enterprise as a whole. This missing description, however, can be inserted between the two terms: An Enterprise IT architecture describes the IT landscape for the enterprise, an Enterprise Data Architecture its data assets.

Architecture describing the XYZ aspects of something (projective)

 “Enterprise Business Architecture” can be used to describe the business aspects of an organization, i.e. the aspects related to achiving its vision and purpose. Enterprise Information Architecture describes the information related aspects of an organization, including their relationship to other architectures.
This use of XYZ architecture focuses on the aspects of architecture related to a specific concern. It therefore comprises the projection of architecture to a viewpoint or set of viewpoints, and hence is highly dependent on stakeholder concerns.

Architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (contextualized)

 When John Zachman wrote his famous paper “A framework for Information Systems Architecture”[4], he spoke about much more than just information systems. His framework considers the context in which an organization builds such systems, and which influence their gestalt.
It is common to perform such contextualization in many compositions of the term architecture, and this approach can be considered as an extension of the constitutional use of the compound.

Architecture consisting of XYZs (compositional)

 When talking about “Process Architecture”, we are by and large talking about a documentation set composed of process documents. A similar thinking is behind the (outdated) perception of data architecture as a corporate data model.

Architecture in the state XYZ (state)

 Using the terms “as is” or “target” architecture describes a state in the development of architecture.

Architecture using an XYZ approach (method)

Architecture organized in an XYZ fashion (organizational setup)

Federated architecture is a way of performing architecture activities in a specific organizational setup. It can be used both for architectural deliverables (where deliverables of a higher level are detailed at the next level) as well as for a way of doing architecture (with a defined distribution of responsibilities between layers).

“Identify 10-12 [application] ‘architectures’ that are standard.  The challenge is to build a decision tree to drive the ideal architecture.

Q1: Are there any defined set of enterprise architectures?
Q2: Are there any decision analysis mechanism (like that for determining architecturally significant requirements in ATAM) already available?”

I’ve seen a few companies attempt to do similar although not quite this ambitiously.  Most organizations have started by identifying common architects that are already in use within the organization and generalizing them.  This has the decided benefit that the architects represent technology components already known to the organization and have proven implementations against use cases relevant to the organization.  I fear any effort to define a standard set of architectures outside the context of a well define problem domain (i.e. the environment of a given enterprise) would be too abstract to be practically applied within any given IT organization.

• The TOGAF Technical Reference Model defines a core taxonomy for describing the components and conceptual structure of an architecture.  http://www.opengroup.org/architecture/togaf9-doc/arch/chap43.html
• FEA (Federal Enterprise Architecture) defines a set of Reference Models for describing the important elements of architecture in consistent ways. http://www.whitehouse.gov/omb/e-gov/fea/
• There are several good catalogs of common enterprise architecture patterns:

• Fowler: Patterns of Enterprise Application Architecture” http://martinfowler.com/eaaCatalog/

• Hohpe & Woolf: “Enterprise Integration Patterns” http://www.eaipatterns.com/

The last part of the problem is even more challenging:  Given a problem how does one pick the appropriate architecture? 

Methods like ATAM are designed to evaluate a given architecture against a given set of requirements.  So using ATAM would require evaluating each standard architecture against the given requirement set and picking the one that fits the best; this would be impractical in the real world for more than two or three architecture.  I’m not sure that inverting the function is possible in a generalized way.  However, if as said before, one narrows the problem domain to a single enterprise and a sufficiently small set of architectures one may be able to define such a function.

The other challenge for picking an architecture based on any given problem is ensuring that the problem has been broken down appropriately first.  Most large enterprises have complex problems, but the successful solution is not an equally complex solution but rather a collection of simple solutions.  Each one of these solution components may map to a different standard architecture.  This componentizing of the solution also simplifies the process of matching problems to architectures since it means both simpler problems and simpler architectures.  Complexity is the enemy.

Another technique for managing the complexity is to divide the standard architectures into layers.  If one limit the problem domain to defining standard physical architects (disk, memory, CPU, networks, I/O, etc.) then this starts to sound a lot more doable.  This may not be the ultimate goal, but it's the start the first step in a layered approach that starts with defining standard physical architects, then standard application architectures, data architects, process architectures, security architecture, etc.  Thus the process of mapping a problem to a standard architecture would actually involve picking an appropriate architecture from each layer.  One may find that each layer has a relatively small set of standard architectures, but in combination the layered architectures represent dozens of complete architectures.  The FEA Reference Models sort of takes this approach.

So whereas the goal of defining standard architectures within an organization has many advantages not the least of which are: reduced technology complexity within the organization, increase reuse of both components and skill sets throughout the organization, decrease risk, and decrease cost.  Unless you happen to be the Federal government of the United States of America don’t look for general solution, focus on the problems in your organization and the tools already at your disposal to develop more specialized solutions that give more immediate benefit.  Where there is some effort, there is some success.

So that’s all I have. It is very difficult for me to anticipate what will be going in the people’s head when they read this blog (so risk is entirely mine) but if you have your wish-list for Santa for SOA for 2010 and beyond then treat this blog space as your home and share with us what your wishes are. Who knows, Santa just might be listening to all this and it could turn out to be a rather serious affair. Wish all of you a great X-mas ahead!

I had attended a workshop on understanding IBM SOA technologies at IBM South Bank London a few months ago.  At the time I was also on a project where we were defining an enterprise SOA based landscape.  So it was quite a good timing with live practical experience on one side and IBM on the other. It proved a rich learning experience, combined with interactions with SOA practitioners from different streams, hands on labs and highly experienced IBM staff. In this post I’ll just focus on the Websphere stack of tools that we were exposed to, and my takeaway feelings about the set of products that we did hands on with.

More or less accurately, the IBM SOA stack comprises of the following,
Stack comprises of

• Rational Application Developer
• Integration developer (Eclipse)
• Service Registry and Repository
• Process Server
• Business Process Fabric
• Business Monitor
• Business Space
• ESB
• Business Rule engine (inbuilt)
• Business Integration Server

There was a guiding case study that took us through implementation aspects of each of these tools in building an SOA enabled enterprise stack.  There was little coding, mostly configuration around these tools. It was a 3 day workshop, but even then with the number of tools to go through quite packed.

Reflecting on my recent engagement within educational sector I touched and felt the SOA architectural challenges again. Going to the workshops to understand the requirements and business processes it was quite evident that the challenges for an SOA architect do not stop with solving only the technical sides of the SOA architecture. The architect must also coordinate and guide the enterprise’s collaboration between business processes, people, information, and technology to ensure the focus remains on achieving enterprise’s goals rather than anything else.
 

Services present the capabilities and the structure of business processes, applications, systems, etc. One typical challenge faced in an organisation is that business processes are intertwined with legacy systems and applications and the obvious consequence of this tight coupling is that it is no longer possible to design one without changing the other. Thus, building SOA architecture must not be considered as purely technical exercise but it is also a business exercise that requires the active participation of key business stakeholders. The immediate impact of business involvement is validation and verification of business services required for development.

Building SOA architecture is a long term journey and should not interrupt the core business functionalities from delivering value and making revenues. SOA will not be built from scratch but it will be depending upon a set of processes and legacy systems. In practice this means that existing business processes and systems will evolve gradually into an SOA and changes are introduced incrementally and rigorously.

 I would like to begin by stating that the title above can be interpreted in multiple ways (yes it’s the word ‘Service’). Hopefully by the end of this blog you will be able to appreciate why I have stated so.
 
In most organisations the IT part has two sub-organisations: One responsible for design/develops the software (equivalent of a car manufacturing plant, at some level) and another which actually support the running software (equivalent of a car service station). The focus of this blog is on the latter.