The Architecture Working Group has completed its first draft of Enterprise IT Architecture Principles.  The work took just over one month, and we really do feel that we have a good list of primary principles that can strategically guide future decisions.

The principles will now be reviewed by the Business Architecture Review Team, and then the IMT Cabinet.

AWG has set out to define a logically consistent and easy to understand set of principles that guide the engineering of APU's information systems and technology infrastructure.  By establishing overarching principles, IMT can better interpret the details of daily decisions in light of an overall strategy.

One thing that has become clear to AWG, is that we can't be everywhere at once.  We can't be on every project team and aren't always able to review project designs and outputs.  These activities keep us rather busy, and movement toward a formalized written Enteprise Technology Architecture has been slower than expected.  We have determined that most beneficial output that we can achieve in short order, are "Architecture Principles" which can be applied across the design decision activities within IMT.

We will do this by considering industry direction, and nailing down the Big Rules that are consistent with our strategy. These should be broad enough to apply to a range of technologies, and stated in clear enough business terms that they can be communicated effectively to both management and user communities.  What we should end up with is something similar to the Seven Pillars of Architecture.

 
The seventh annual Educause Current IT Issues Survey Report highlights two areas which I have been following.  First, Security & Identity Management (IdM) rose to the top, displacing IT Funding as the most strategic issue needing to be resolved for future success.  Second, Portfolio Development & Management was a new category this year and immediately received attention, appearing among the top-ten issues expected to become more significant in the coming year.  Other issues I have been tracking of late were also covered, including ERP, Academic Alignment, and Web Services (SOA). 

Here are some of the highlights from the report, with additional resources referenced at the end.  Overall, this report is a treasure trove of Higher Education IT strategic thinking:

As the infrastructure maintenance and PC support operations mature, an IT department must continue to innovate. Its value proposition is the packaging and distribution of meaningful services aligned with the business needs. It includes partnering and consulting with customer groups in innovative spaces like collabortion, web publishing, and self-service. A higher level information creation and distribution channel needs to be created to support rapid assembly of reusable components. If given tools, advanced user groups should be able to build communities which can meet their own lightweight application needs, filling gaps that a centralized transaction system is not meant to.

Will IT Departments Still Exist in 2010? ...

There is much talk these days regarding Service Oriented Architecture (SOA) and the focus is primary geared toward software. In an SOA, modular distributed software provides services which can be aggregated and negotiated on the fly to solve complex problems. But are IT departments ready for an SOA software architecture if they are bogged down with the maintenance of infrastructure, instead of developing maintainable services.

Perhaps I am a bit off with this, but it appears to me that the proliferation of the Personal Computer has much to do with the transition from Information Services to Information Technology. So much time is spent simply providing and maintaining technology devices and the infrastructure that supports them that there is little time left for anything else.

Without architecture, there is little left between strategy and implementation. Some would say projects are between strategy and implementation. But as someone pointed out to me recently, strict project management is about doing the things the right way, not necessarily doing the right things. How do you know what to do and when to do it? And how do you make sure you have enough resources available to do more than catch up with support response?

Architecture is not infrastructure. Infrastructure relates to the maintenance of technology components to provide utility. Architecture is the the mapping of infrastructure to services to business needs; it is the definition of the information supply chain. Where has MIS gone? Who needs what information when? And how do they get it?

In the early days, Data Processing departments housed the data repositories, information was requested centrally, and experts made computers transform data into information; or in some cases only generated enough data for management to turn into useful information. Today, Information Technology departments largely supply the vehicles for users to produce and consume their own data. Somewhere between the two value-add has been lost.

What is the product that modern IT organizations deliver? Should there not be product lines, or services, which are evaluated in a similar portfolio as in a manufacturing or service company? How are those products and services evaluated for success?

Is not the success of a service partially defined as one that meets real customer needs, authenticated by increased use over time, sustained by reduced marginal cost of continued delivery or expansion.

What defines a failing product or service? One which is used by fewer individuals and costs more to maintain each year. Without removing failing products, eventually 100% of IT budgets will go toward maintenance.

So many solutions delivered by IT organizations meet a single need well, and yet shorten the horizon of future opportunities. The primary goal of architecture is to reduce complexity and thereby eliminate the inhibitors to change. Can we draw some lines that allow us to understand how today's decisions affect tomorrows opportunities?

A recent article in CIO Magazine, raises a valid point about the communicated purpose of Enterprise Architecture. Enterprise Architecture can be an overwhelmingly complex undertaking if approached comprehensively from the top down. In order to avoid getting lost in the matrix of the Zachman Framework, EA should be attached to solving business problems, and according to GM CTO Tony Scott, business peers shouldn't even know its called "enterprise architecture".

The goal of EA is to Reduce Complexity, not increase it. EA is described simply as the mapping of business requirements and processes to IT systems which support them. But its not a technology platform, or a one time mapping. It is a discipline. We don't sell disciplines, we practice them.

The EA discipline is practiced when key problem areas, inefficient processes, legacy systems, those things which can no longer be directly connected with the business need are re-evaluated. The goal is to provide agility, reduce complexity, so that the organization can "change the business rules" when need dictates without reinventing the IT systems that support them.

Often IT is viewed as slowing down the advancement of the organization, rather than enabling it. Strategic alignment has been thwarted by the increasing complexity of ad hoc computing solutions. IT is too busy just keeping the plethora of individual PC's, components, and nich products running. It seems like products are always being added, never removed. Clearly re-alignment is necessary, discipline is the key.

Michael Schrage wrote recently in an Article in CIO magazine about the variance in the usefulness and definition of agility.

I think Schrage makes some valid points, buzzwords, initiatives need to be defined. And agility is much different than hacking around a previously unforseen problem. Also it does make sense to ask the question "agility for whom?". However, I feel like he fails to make a valid actionable point. Especially refering to the fact that architecture for buildings does not have as its purpose changeability. This is true, but no one is saying that IT architecture approaches the problem of design in the same way as building architecture. In other words, using the term from one industry in another (Architecture) doesn't mean it inherits all the problems of the source industry. ie. static buildings.

The true point of agility is to remove the inhibitors to change, and if done correctly this benefits all parties, except perhaps vendors selling monolithic product suites. What helps programmers take less steps to modify software, is the same thing that benefits administration who says tomorrow we are going here instead of there. Benefiting the "enterprise" is a worthy goal, albeit a bit abstract.

Can persons build architectures in a vaccuum that are far from practical? Absolutely. Do architects need to keep this in mind as they approach solutions? You bet. Just enough architecture just in time, should be the model, not the white tower of IT consolidation and governance.

Sometimes IT thought leaders have to say no to something that benefits the organization in the short run, because it pigeon holes them in the future. But in desiring to build an environment that removes the inhibitors to change, they themselves need to make sure their not in the way.

Well this ends my first week back after the EAC conference. As I might have expected I didn't feel like blogging from the hotel in the evenings last week. Too much input during the day to spend any cycles outputing at night.

Anyway, I was fully emersed into the broad area of enterprise architecture. From theories on how to engineer an enterprise, to practical methods of defining solution patterns for re-useable technical architectures. I have many personal notes, and presentation slides from all the sessions that I need to parse through and synthesize into some sort of actionable material.

I think the most interesting facet was examples of how organizations are integrating the function of EA into their functional areas. Such as the important relationship with the project process, as well as with executive steering committees. Certainly the architects field is a difficult one, but I think if I would have dived into the industry material a year ago (such as the book, "Practical Enterprise Architecture" from Prentice Hall I am reading), I would have been more productive in my first year in the position.

How does an organization create blueprints for the who, what, how, when, where and why of the enterprise, when its busy moving from project to project. Projects are the executing arm of our service industry, and we all need to be involved in them. In fact, early in the EA maturity model, it is the means by which architecture is reviewed. However, unless time is spent creating models and re-usable patterns, then each project will require signifigant investment individually enginering a solution. We need to get to that place.

Besides getting re-aquainted with my desk this week, I spent a bit of time on a few projects. Created a process diagram for the "Policies on the Web" project, and also have been reviewing a Benefits ASP web offering HR is looking into. I don't know much about the HR module for IFAS, but there really isn't any functionality in the area of self-service benefits administration. There is double entry data input going on, and we all know the manual process we go through to select insurance cariers etc, so there is a real need here. We'll be meeting with HR again to understand their business process and how it relates existing systems. Any movement toward a solution will need to integrate with something, and we need to make sure the bridges can be made. I look at it as a great way to develop some understanding of existing architecture in a functional area I haven't spent much time in.

And thats how we do it. One area at a time, answering the basic questions of what, how etc. According to the EA maturity model (there are several flavors of course), many organizations start out knowing they need architecture, so it starts with a person or a few persons providing input to decision making processes. Then standards are defined, usually an overly specific list of which products/protocols you will and won't use (sound familiar?), then realizing thats too narrow, a principled based architecture is approached. So whats next? A broader framework, an EA template with great questions that we need to find the answers for. These are questions that are being answered each day, in different ways by different folks.... we need a blueprint for how each part of our components work together to provide services.

Eventually I hope that we can have a SOA (Service Oriented Architecture), where processes and functionality are more important than the specific widgets that deliver the results. Mix and match.... flexibility because of good design and some slack. To steal an analogy... you know those little plastic puzzles that we all played with as a kid, with the little squares you could slide around until you got the pattern correct? Well the most important piece of the puzzle was the slack, the empty space. Without the empty space you cannot rearrange the pieces in order to achieve your goal.

I don't blog enough. Sometimes we desire to create the perfect post every time. Spending time and breaking continuous thought by linking to sources and messing with formatting. But blogging is useful not for publishing finished work, but for getting out thoughts quickly to develop over time. Its the process that is more important than the result in this case. So thus, my ramblings for this work week.

APU, like most organizations, can produce more data than can be turned into long-term knowledge. With so many means of producing ad-hoc unstructured data, whether it be Microsoft Office, Email or even web pages, it becomes apparent that a strategy is needed to store, search, retrieve, share, and archive content.

Welcome Enterprise Content Management (ECM)

The term ECM, does not represent just a product or a suite of products, nor simply a group of technologies. While ECM includes the aggregation of once disparate approaches to the information management (Document Management, Collaboration, Knowledge Management, Digital Asset Management, Web Content Management), the ECM concept represents more than simply the sum of their overlapping characteristics. It is the systematic re-thinking of the approach to the creation, management and distribution of all data stored outside of traditional integrated information systems (ERP, SIS etc.).

IMT's first quandry into a broader perspective of this area is covered in a whitepaper, Document Management - An APU Definition and Application. We are now revisiting this opportunity domain, please read on to ECM Defined.

This is what is called a collaborative book, for the development of the Sub-Architectures of the Enterprise Architecture. An Enterprise Architecture (EA) is not a one time single document, but rather a collection of models and principles that provide a mental model of organization. Architecture defines the relationships between entities within an organization, just as an architectural blueprint for a building shows the interconnection between parts. Without a blueprint, one can't determine the result of changes made to any individual part on the whole. Enterprise Architecture's goal is to remove inhibitors to change, so an organization can continue achieve its objectives in a constantly changing environment.