Archive for August, 2007
| |
|
|
|
|
|
|
In my last post, I posted an except from a strategy document I am working on around the creation of a Composite Application Framework (CAF). The section I posted dealt specifically with the need for application composition within IT. Soon after I posted, Mike Walker, an Architect with Microsoft’s Architecture Strategy team, posted a response with some thoughts of his own. As I said in the comment section of that post, I think Mike’s additions were right on and plan to incorporate some of his thoughts and comments as I revise that section in the final publication.
In the first section of his post, Mike took a moment to define the term “composite applications” using definitions from Gartner, BEA, IBM and pointed to Chris Keyser’s Architecture Journal paper from January, “Composite Applications: The New Paradigm.” The last was a key piece of my research and I highly recommend reading it as it discusses composition from a broader view than just SOA, which is contrary to the focus of most first generation thinking on composite applications.
Mike’s definition aligns with what I included in the second section of my research paper, which I am posting here. This section shifts the focus from justifying the need to understanding all of the terms in the CA universe as we’ve defined it. Thus, it includes a bit more than just defining Composite Applications. Mike, I’d be interested in further thoughts or feedback you might have on this section. Same goes for anyone who wants to jump in. Here’s section two:
In order to create a Composite Applications Framework (CAF), one must first understand the vocabulary of composition and composite applications. This section introduces several terms and concepts important to the creation of a CAF. They are:
1. Composition
2. Composite Assets
3. Composite Applications
4. Composition Tiers, Composite Types and Containers
5. Composers
According to Wiktionary, composition is the combining of different parts to make a whole. In the context of technology, composition is the combining of technology assets to create an application or solution which provides value to the business. According to Keyser, the term itself is a “… shift in computing from brittle, monolithic, developer-centric applications solving one particular problem, to agile, contextual, user-driven applications to support a particular business process.” (2006, p. 5) In addition to agile and user-driven applications, composition also “… includes personalization and customization abilities, so that users can easily and quickly modify specific functionality in the solution.” (Banerjee, What are Composite Applications?, 2006) In essence, composition is the assembly of assets into applications which can be created and/ or modified quickly and are user-driven in nature. Thus, enabling composition of assets into applications is the key and ultimate goal of a CAF.
Within the realm of Composite Applications, a composite asset is a discrete object with standalone value and functionality which can be combined with other objects to create an application of greater value than the sum of the individual objects. Typically, this combination is in support of a business process or set of user goals. Within a CAF, the following objects can be considered assets for composition (Adapted from Banerjee, Building Office Business Applications, 2006 and What are Composite Applications?, 2006):
It should be obvious from this list that the creation of composite applications goes far beyond the assembly of WebParts on a screen to create a single interface. In fact, composite applications span all of these types and all of the traditional application tiers. To create a successful CAF, IT should create a CAF that allows most, if not all, of the assets listed above to be used in the creation of Composite applications.
The term “composite applications” evokes many different meanings in the current landscape of information technology. A few examples are:
- Applications created via the assembly of SOA services;
- The Business user’s equivalent of Web 2.0 “mashups;” (Keyser, 2006)
- Another form of integration and application development; (Frye, 2005)
While these are all valid interpretations, they are also nearly all tied to first generation ideas around the meaning and intent of composite applications. Core to that idea was that the only useful assets for composition were either Web Services or entire User Interfaces. Thus, much of the current writing and thinking around composite applications centers on either the composition of fine-grained SOA services into “right-sized” business services, which are then wrapped in a UI and delivered to the user, or the creation of Web Parts which are dragged onto a portal screen, skinned and placed wherever the user desires.
While we still hold the first generation thinking around composite applications to be true, we believe that composition is more than simple service composition or the creation of WebParts. Furthermore, composition is a reality for all of the assets listed above and also at every tier of an application and for each major type of composite application. Thus, a candidate definition of a composite application is “… a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.” (Banerjee, What are Composite Applications?, 2006, p. 12)
Because a CAF should support more than service and WebPart composition, it is important to understand the tiers of composite applications, types of composite applications and the containers available at each tier. An understanding of each enables solution teams to determine the appropriate placement for a composite application.
Composition Tiers are application layers that provide services to composite applications.
Composite Types are categories of composite applications which map to each composition tier.
Containers are shells which can host any or all of the assets that make up a composite application.
Presentation Tier - UI Composites
The primary function of the presentation tier is to present business information to knowledge workers and actions to perform on said information. Composition at this tier is called composition “at the glass.” (Sholler, 2006) UI Composition is one of the most common forms of composition and is often assumed to be the only tier at which composition takes place because of its broad use and visibility. However, this misconception often causes organizations to attempt to create a CAF simply by creating a “whole cloth” UI through which all applications must be surfaced. The result is a single interface (instead of a unified User Experience) which ends up constraining business users and diminishes the value of a CAF.
Instead of a one-size fits all CAF with exclusive UI composition, organizations maximize the value of a CAF by leveraging composition at the level where it is the most appropriate option for a given composite application. In the case of UI composites, these are most appropriate when the resulting composite application should describe the sequence of interactions the end user will need to follow in order to use the application. (Sholler, 2006) In addition to sequenced composites, UI composites are also appropriate for “informal and unintended compositions.” (Keyser, 2006, p. 3) In both cases, an Enterprise Portal environment is the ideal host for these types of composite applications.
Application Tier - Service/ Integration Composites
Composition at the application tier typically involves the creation of new services from existing services to enable a business process or set of user goals. Composites created from existing services are new services themselves which may also be candidates for composition. These services are usually managed by an integration/ orchestration engine such as Microsoft BizTalk Server. Similar to Presentation Tier composites, these composites can have UI elements and trigger user interactions, but the key difference is that the actual composition takes place at the service level. These types of composites are most appropriate when the composition describes automated business activities or a subset of an automated business process. (Sholler, 2006)
Data Tier - Data/ Information Composites
Composition at the Data Tier consists of creating services for managing the content and relationships of a business entity. These services are designed to be the building blocks for the creation of other services and are typically not surfaced to a UI. Data Tier composites are most appropriate for consolidating views of shared reference information and are usually the foundation for SOA. Key to the success of Data Tier composition is the establishment of Enterprise Information Management (EIM) processes and practices in an organization. EIM practices, especially those targeted at Master Data Management (MDM) go a long way toward addressing many of the entity aggregation and information integration issues which typically plague SOA and CAF implementations.
Productivity Tier - Ad-hoc Composites
Productivity Tier composites are composites used to manage the “rhythm of the business:” those ad-hoc interactions, collaborations and processes which all knowledge workers rely on to accomplish their goals. While discussions around SOA, Enterprise Service Buses (ESBs) and open standards like WS-* and Service Component Architecture (SCA) are valuable, they are all focused on managing and exposing structured business logic. However, the greatest business value for composition can be found at the Productivity tier. (Keyser, 2006) Furthermore, the very idea of composition begs for a framework which supports ad-hoc processes. According to Banerjee, “By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed-and so need to explicitly account for people-to-people interactions among information workers that are essential to complete any business process. Usually these interactions are not captured by structured processes or traditional business applications.” (Banerjee, Building Office Business Applications, 2006, pp. 12, 13) These types of composites are most appropriate when processes either cannot or need not be defined, or when the business requires a solution that works “in between the boxes” of defined processes.
Each of these tiers and types provides a set of containers within which assets can be hosted. Examples of containers at each tier are:
- Presentation - Outlook, Excel, InfoPath, WSS WebParts
- Application - Web Services, LOB Systems
- Data - Analysis Services, Data Warehouse, EIM services
- Productivity - MOSS Document Libraries, Excel Services, Workflows, Business Data Catalog
One of the key questions related to the creation of composite applications and a CAF is “Who composes?” That is to say, “What roles would be involved in the assembly of composite applications?” Organizations have several options when determining the primary composers of composite applications and the choice has implications on the design of both a CAF and the experience in creating composite applications. Some likely composers of composite applications are:
These are IT developers focused on providing value-added common business services to all customer solutions teams. Their technical depth is high and a CAF targeted at these users would be similar to what is provided by SOA today.
These are IT developers focused on creating customer-centric solutions by leveraging software infrastructure. Their technical depth is moderate to high and a CAF targeted at these users would need to abstract away service creation and assembly.
These are customer consultants focused on helping customers determine which business needs are best met with technology. Their technical depth is moderate and a CAF targeted at these users would draw many features from current leading BPM platforms.
These are the users of the solutions created by customer solutions teams. Their technical depth is low and a CAF targeted at these users would need to abstract away nearly all of the technical aspects of application creation and should provide very intuitive context- and metadata-driven methods for application assembly and customization.
For many organizations, it would be advisable for a first generation CAF target Customer Solution Developers as the primary composers of applications, with some configuration, customization and personalization provided to business analysts and end users. Once the CAF is in place, the framework should evolve over the long term to push composition out to Business Analysts and eventually to end users.
References
Banerjee, A. (2006). Building Office Business Applications. The Architecture Journal, (10) 12-19.
Banerjee, A. (2006, December). What are Composite Applications? Retrieved August 20, 2007, from MSDN Architecture Center: http://msdn2.microsoft.com/en-us/architecture/bb220803.aspx
Banerjee, A., Moinuddin, M., & Walker, M. J. (2006). Office Business Applications: Building Composite Applications Using the Microsoft Platform. Redmond: Microsoft.
Frye, C. (2005, July 20). The role of composite applications in an SOA. Retrieved August 20, 2007, from SearchWebServices.com: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1109080,00.html
Keyser, C. (2006). Composite Applications - The New Paradigm. The Architecture Journal , (10) 2-5.
Phifer, G. e. (2007, July 13). Hype Cycle for Web and User Interaction Technologies, 2007. Retrieved August 20, 2007, from Gartner
Sholler, D. (2006, December 12). Three Approaches to Building Composite Applications. Retrieved August 13, 2007, from Gartner
|
|
|
|
| |
|
|
|
|
|
|
If you’ve been following me on twitter, you’d probably be able to venture a guess as to why I’ve been mostly silent for the last two weeks: I’ve been frantically working away at an internal strategy and vision for a Composite Application Framework (CAF). I finished a draft Wednesday and am going through a self-imposed peer review process before publishing next week. In addition to internal peer review, I wanted to start engaging some peers in the blogging world for their opinions on the ins and outs of both the need for and the creation of a CAF in an enterprise. Part of that includes, of course, some discussion around the meaning of “Composite Applications” and CAF, which has several meanings: from being synonymous with SOA (only the beginning IMO) to Web 2.0 in the Enterprise (or Enterprise 2.0 if you like, which I do not). However, before I get into the weeds of terminology, I wanted to share an excerpt from the document that establishes the need for composition period, be it via SOA or Web/Enterprise 2.0. I’ve taken out anything specific to my company, but the rest is true to the first draft of the doc. I would love to have feedback from Mike Walker, James McGovern, Todd Biske, Nick Malick, Mike Kavis and anyone else who wants to weigh in. Going forward, I plan to post some additional sections from the doc for your consumption, review and feedback of any kind. I hope it at least generates some good discussion. So without further ado…
To understand the value that a CAF provides for an organization, it is important to first understand environmental trends which are driving IT organizations to reevaluate their current delivery models and to pursue composition strategies. In particular, I believe that there are five factors which illustrate the need for an application composition strategy. These factors are:
- The Cost of Building Applications
- The Problem with Processes
- The “Consumerization of IT”
- The Need for Agility
- The Desire for a Single User Experience
 A current reality many organizations face is that IT costs are increasing while businesses are asking for more controls on IT spending. While the high cost of IT solutions isn’t new, more and more organizations are pointing to the cost of integration as a major culprit behind IT cost overruns. According to Ebstrategy.com, “The cost of integration is rapidly becoming a significant barrier to the deployment of new business applications. EBS estimated that in large corporations, approximately 40% of the cost of new applications is spent linking disparate business processes and applications rather than delivering new business functions.” (E-Business Strategies, Inc.) Furthermore, Dr. Jean-Jaques Dubray of Attachmate argues that increasing integration costs are a sign that IT is nearing or has crossed the point of “negative ROI,” beyond which the costs, risks and complexity of integration make it nearly impossible for the organization to realize any ROI from its efforts. (2005, p. 9) The figure above illustrates this theory of increased cost and decreased value as the number of systems in an organization increases.
As a result of this increased cost, Dubray concludes that “…companies are limited in their ability to improve existing business units operations or expand their businesses because all changes in a company’s operation translate into modifying or creating new [Line of Business (LOB)] systems.” (2005, p. 9) The increased cost of applications due to integration cost and the resulting limitation in IT’s ability to deliver value to the organization contributes a great deal to the perception that IT is too expensive and slow to respond to the needs of the business.
In response to increased cost and this perception, Dubray argues that IT ”…can no longer afford to build assets that cannot be reused in future contexts.” (2005, p. 9) Instead, IT must view everything it creates for the business as a collection of discrete and reusable assets. In addition, IT must create a framework that enables both the creation of reusable assets and the reuse of those assets in the creation of solutions.
 The systems that IT creates are typically designed to manage discrete steps in a structured process. An example is web content creation, which typically involves story creation, moderation, publishing and retirement. Historically, IT systems have focused on automating approval, publishing and retirement and have been successful at creating value along these steps. However, the largest step in this process (in terms of elapsed time) is usually the first: story creation. It is also likely the most collaborative and would likely consist of several “ad-hoc” process steps where the author collaborates with other individuals to check facts, obtain more information and even elicit feedback on the document in progress. But the system in question assumes that a completed draft is step 1 in the process. The result is that most applications “…do not enable rich collaboration across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this in turn leads to a loss in productivity, as users are forced to cross from one set of tools to another, often manually moving the data through means such as cut-and-paste.” (Banerjee, 2006, p. 12)
IT cannot focus merely on process automation to create value for the business when the reality is that most processes involve “…much more work between elements than is represented in the initial structured process. This work is often collaborative in nature. Innovation frequently takes place outside structured processes in the collaboration interactions, where imagination predominates, where the creativity of information workers is truly tapped, and where the critical business differentiation occurs.” (Keyser, 2006, p. 3) Instead, IT should seek to create applications that enable and enhance the productivity of information workers along both structured and ad-hoc processes, as illustrated in the Figure above (Banerjee, What are Composite Applications?, 2006).
The “Consumerization of IT”
 The “Consumerization of IT” is a term coined by Gartner to describe the effect of popular technology outside of the enterprise on the expectations and needs of knowledge workers within the enterprise. Gartner argues that knowledge workers are learning new and creative ways to use the web for productivity and collaboration and that they will expect to have these methods and tools available to them in the workplace. According to Keyser, “Based on working with Web 2.0, users will increasingly expect to exert more control over their work experiences and to participate in them. They will expect business applications to adjust to the way they work, rather than accept a suboptimal experience.” (Keyser, 2006, p. 2) An example of this shift has been illustrated by a recent poll conducted on Facebook.com by the Gilbane Group (Gilbane, 2007).
In this poll, participants were asked to select from a list of collaboration technologies which they plan to use in their jobs the most over the next two years. The respondents were then broken up into two groups (18-24 year olds and 25-34 year olds) and a visualization of the results can be seen in the figure above. While it’s a bit of a surprise that younger knowledge workers will expect to use social-networking sites and SMS text messaging as a part of their jobs and not merely for play, a key piece of information in this unofficial poll is that many younger workers would prefer not to use email as a collaboration tool.
The implication, in my opinion, is that IT cannot paint users into a corner by offering one prescribed way in which to accomplish a task or achieve a goal when another tool or method might enable users to be far more productive. In reality, the “Consumerization of IT” means that the use of technology and the tools at an information worker’s disposal are becoming a large part of job satisfaction outside the walls of IT. IT organizations should recognize this trend and seek to provide solutions with the flexibility to meet the technology demands of information workers.
Many organizations frequently express a desire to obtain the flexibility to quickly respond to meet new opportunities and demands as a “high priority” which they expect IT to enable. (Keyser, 2006, p. 2) As an organization grows, there is an increasing need for IT to provide the organization with:
- A platform for rapid decision-making;
- Tools to help the business sense and respond to changing market conditions;
- The ability to align business needs with current and future IT assets.
To support these business needs, IT organizations should be able to provide applications which are:
- Quick and easy to deploy;
- Easy to modify, customize and extend;
- Aligned with the current and future needs of the business.
All of these factors illustrate the need for IT organizations to provide infrastructure and solutions which enable an organization to respond quickly and easily to change.
As organizations grow their products and services, they typically outgrow the LOB systems they purchased or built to manage their earlier products and services. Those legacy systems are typically run to support the existing business, while new systems are created in new interfaces and bolted into the organization to run new businesses. The result for most users, who typically work with similar business processes across all products and services, is a small to large number of disparate systems within which they perform their daily work. Over time, the business begins to call for integration and a unified User Experience for knowledge workers in an organizations. Organizations who have been successful at implementing SOA usually lay the groundwork for meeting this need, but the path to a single User Experience includes a framework which brings data, processes and interfaces into a shared and consistent experience for knowledge workers.
It is important to note here that a single User Experience is not a single user interface or a single system. Rather, a single User Experience is offered by a platform and a controlled number of user interfaces which provide familiar interactions to knowledge workers regardless of the medium, be it Office client, web application, mobile device or smart client.
References
Banerjee, A. (2006). Building Office Business Applications. The Architecture Journal, (10) 12-19.
Banerjee, A. (2006, December). What are Composite Applications? Retrieved August 20, 2007, from MSDN Architecture Center: http://msdn2.microsoft.com/en-us/architecture/bb220803.aspx
Banerjee, A., Moinuddin, M., & Walker, M. J. (2006). Office Business Applications: Building Composite Applications Using the Microsoft Platform. Redmond: Microsoft.
Dubray, D. J.-J. (2005, May). Composite Applications: Value Proposition and Architecture. Retrieved August 20, 2007, from ebMPL.org: http://www.ebpml.org/capp.ppt
E-Business Strategies, Inc. (n.d.). Composite Applications - Frequently Asked Questions. Retrieved August 20, 2007, from EBS Web Site: http://www.ebstrategy.com/selfservice/composite/composite_apps_faq.htm
Gilbane, F. (2007, June 20). More Data on Facebook users and Enterprise 2.0. Retrieved August 20, 2007, from Gilbane Group Blog: http://gilbane.com/blog/2007/06/more_data_on_facebook_users_an.html
Keyser, C. (2006). Composite Applications - The New Paradigm. The Architecture Journal , (10) 2-5.
Platt, M. (2007). Web 2.0 in the Enterprise. The Architecture Journal , (12) 2-6.
|
|
|
|
| |
|
|
|
|
|
|
- SSIS Team Development Experiences - Another example of database developers being left out in the cold when it comes to first-class development tools and practices. It’s getting better, but we’re not there yet…
- Adaptive Path UXWeek - Simon Guest is at UXWeek and will be blogging about the experience. I hope that the number of EAs only increases in coming years and hope to attend myself in the future.
- Go old school with a notebook - I’m a tried and true notebook guy. There is no and never will be an adequate replacement for pen and paper for me…
- User experience and the analysts - A nice piece of research done by Rosenfeld Media on major Analysts use of certain UX-related terms. The Gartner ones weren’t surprising to me as a Gartner client (though I would imagine that they would argue that the “Consumerization of IT” term is a UX term, thus should be on the list), but it was interesting to see some side-by-side comparisons. More research along these lines would help an organization like mine have some good insight into which firm, if any, should get our money.
- DSLs bringing the end of single language development? I hope so… especially if one is more open with the terms “language” and “development.”
- Are You a Synthesizer? Enterprise Architects have to be… I sure hope I am. If I’m not, I’d like to become a professional fly fisherman…
- Enterprise 2.0 is about building a collaboration platform that is better than e-mail - The reality, as Jason states himself in this article, is that Enterprise collaboration (I won’t use that term in the title) is less about replacing email and more about repositioning email to be used correctly (messaging) and bringing other tools into the enterprise which are better suited for collaboration (like Parlano). (via Joe Lewis)
|
|
|
|
| |
|
|
|
|
|
|
- Microsoft: My way or the highway with SOA? Though Microsoft can certainly afford to do “SOA their way” and though such approaches have certainly worked in the past, I wonder if this one might actually hurt them is the long run. As Joe says, “What Microsoft appears to be doing… goes completely against what SOA is supposed to be all about, which is the ability to deploy and run what you need based on what you need, unencumbered by the limitations of vendors’ systems.” Wouldn’t it be ironic if Microsoft’s way of forcing organizations to “do SOA” causes organizations to turn to SOA itself as a way to minimize their dependencies on Microsoft systems?
- Project Zero: IBM enables REST-based development - Not surprising to see IBM adding support for REST, especially since Microsoft is doing the same by adding a Web Programming model to its WCF upgrades in the .NET 3.5 Framework. In many ways, this simply underscores David Chappell’s assertion that the REST versus WS-* debate is over. While we may still have a place in our hearts for one over the other, the major vendors seem to be saying “why not both?”
- Binding SOA to BPM instead of BPM to SOA - Not sure I understand the assertion that we should attach SOA to the swimlane diagram and not BPMN Nick. Pools and Lanes are used heavily in BPMN, so what is it about BPMN that you have an issue with? If it’s the BPEL/automation side of BPMN, then I agree, but I think that BPMN can be very useful to organizations without that side, especially since what you get is a standard Process modeling language where none exists today.
- Why Sales isn’t process driven - According to Steve Jones, the “mechanism for the implementation and measurement of a service” (process) isn’t always the same thing as the drivers for and value of the service (goals). Meaning that our services ought to pay attention to user goals first and the underlying process second. It’s a UCD/UX perspective for SOA…
- PowerPoint: Boon or Bane? I tend to fall into the camp of PowerPoint is a misused tool, not a bad tool in and of itself, though its conventions in the form of automatic title and bullet regions do encourage bad behavior.
- Stuff - I read recently that it took the self-storage industry 25 years to build the first billion square feet of storage space and only 8 years for the second billion. Yet our houses have grown by 80% and we still face a storage crisis. Stuff is best gotten rid of…
|
|
|
|
| |
|
|
|
|
|
|
-
-
Do Enterprise Architects ask Stupid Questions? - There are no stupid questions, only questions that self-righteous people think are stupid.
-
Build versus Buy versus Opensource - Good advice if you can get Opensource in the door. Of course, vendors charging a premium to solve common problems already solved should be reason enough to adopt opensource…
-
Loc.alize.us - A Google Maps and Flickr mashup that brings photos of different lands to you. I’m planning a trip to Italy right now and it’s nice to be able to get more than just the top-down view that Google Earth and Maps provide. Google Earth has functionality similar to this, though I like the UI here better.
-
What SOA needs to learn from Ruby On Rails - Though I’m not sure what “Canned SOA” would look like, I agree with the argument that SOA needs some measure of default convention which can be leveraged.
-
The Developer Theory of the Third Place - My third place is usually one of several coffee houses or restaurants with free WiFi close to my work or home. BTW, If you’re ever in Colorado Springs Scott, we’d love to have you drop by and share some of your expertise.
-
Free Code - Getting IT out of the Applications business - IT takes EIM and the Business Event Ontology and gives the business (Biz Process Devs specifically) the ability to write “free code.” While it sounds a little counter-intuitive, it certainly has some promise.
|
|
|
|
| |
|
|
|
|
|
|
I’ve spoken a bit recently about Enterprise Architecture as a collaborative tool, rather than a command and control structure. Talking about collaboration is good, but it takes more than a desire to collaborate to move EA in that direction. In reality, collaboration is an intentional effort, not just something you do by getting a group of people together and talking about architecture. While that’s a key first step, and one you can do right now to improve your current landscape, collaboration is a culture which must be encouraged and fostered and which requires stronger leadership than any command and control structure ever does. But I don’t want to talk about the soft skills of leadership today. Instead, I’d rather talk in this and another post or two about tools that make EA Collaboration a richer and deeper experience. By tools, I don’t mean modeling tools, repositories or frameworks. Those things have their place, but EA is also about people, and the tools of which I speak are tools that help people work together. These are common, simple tools that don’t cost an EA team much, but which can add a good bit of value to your efforts.
The first is a communication tool called a RACI Chart. A RACI chart is a simple device used to describe  the roles and responsibilities of a group of people in completing certain tasks or deliverables. An example of a RACI chart from Wikipedia is depicted on the left and illustrates tasks or deliverables as rows (what is being worked on) and roles as columns (who is working on it). At the intersection of each task and role is a letter (R, A, C or I) to represent a role’s level of involvement in a task. Here is the meaning of each letter:
- Responsible - The person who does the work. (There can be multiple)
- Accountable - The person accountable for the completion of a task, or the “single wringable neck.” (There can only be one)
- Consulted - A person or people with input into the task. Their expertise is needed.
- Informed - A person or people who “need to know” the outcome, but who need not be consulted during the process.
So why is this valuable to EA? For me, the reason is because it removes assumptions and brings clarity to collaboration. RACI charts enable a group to go into a process or task with a clear understanding of everyone’s role. Differences of opinion over the level of involvement are resolved up front, which makes it that much easier for a group to move forward on the “same sheet of music” so to speak. Without clarity, you usually create conflict around contribution (bad), rather than conflict around content (good).
Here’s an example of a RACI chart that lists some common Architecture deliverables (both Enterprise- and Solution-level):
I won’t go to deep into the content here because the deliverables and roles don’t apply to every organization. For that matter, neither do the structural and cultural issues that play into “correctness” of this particular chart. The key is to recognize that the chart clearly identifies Rs, an A, Cs and Is for each deliverable listed as they relate to various roles in the organization. On the occasions where I have leveraged this method in the past, I was encouraged by the clarity it brought to the teams with which I was working. On one occasion, I was told that this model helped one individual put his finger on some past frustrations he had around certain deliverables and also understand with clarity how he “fit” into these cross-functional decisions.
Of course, these charts are no substitute for open and honest discussion and they should never be used as a way to manipulate people. They are intended to bring clarity and should be used only to obtain it. Once you’ve got it, it’s time to move on to the task art hand, which you’ll do with a lot more clarity than you would have otherwise.
|
|
|
|
| |
|
|
|
|
|
|
- Never Email Anyone Over 30 - I’ve seen many enterprises that think that Email + IM = collaboration needs met and I find it pleasantly surprising to see that IM as a collaboration tool is diminishing in the eyes of the younger generation of workers in favor of things like SMS, Wikis and Blogs (Twitter is probably just about in its own category). What that means however is that the enterprises who are just now getting IM in the Enterprise are still behind the curve… so what’s your strategy for embracing the next generation of collaboration tools? Does an Enterprise vendor have to offer it before we’ll buy it?
- Practical Enterprise Architecture - Some good tips on creating valuable Enterprise Architecture.
- What is Enterprise 2.0 - As much as I don’t like the phrase, or “concept versioning” in any form, I like what the idea represents in terms of driving information access, interconnected applications and devices and collaborative and open work.
- SubSonic - This looks to be a very nice ASP.NET scaffolding framework that parallels much of the project start-up scripts that makes Ruby on Rails such a nice environment to work in. (via Ken Scott)
- Should people adapt to computers? - Agreed Scott. I think that people have adapted enough… it’s time to set them free, and I don’t mean by turning their coffee table into a computer either.
- Enterprise Architects versus Business Architects - While I certainly don’t think that the role of EA is to create services within an Enterprise SOA, I do think that EA has a responsibility in handing valuable business process knowledge to an SOA team that then knows which services are needed. Otherwise, services end up being created to wrap whatever database entities a given project needs next. In any case, the key is that EA has a responsibility to be relevant to SOA efforts, not the other way around.
- Enterprise Architecture is like Herding Cats - Don’t know what I could possibly add here…
- Is Serendipity the Heart of the WS-*/REST Debate? Serendipity is probably a large part of the discussion, but I think a key to Nick Gall’s General Principle of Serendipity (”Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.”) is that one can rarely (even in an enterprise) plan for explicit reuse of a service. As such, you plan for serendipity.
|
|
|
|
| |
|
|
|
|
|
|
- Daily Lit - Get daily installments of public domain books delivered via email or RSS. I’ve started with Walden and should be done in 124 days… assuming I read these installments daily, of course.
- The Manifesto of the Futurist Programmers - There’s nothing like a thousand words of propaganda to get your blood boiling over vague ideas and foggy platitudes (via CodingHorror).
- Does Visual Studio Rot the Mind? - A great article from Charles Petzold on the ways that Visual Studio might hinder us as programmers. From a User Experience perspective, I think that the broader critique here is that systems which define our way of working instead of conforming to our way of working probably cost us more than we realize.
- Ha Ha, you must be joking - This is what happens when governance isn’t seen as an enabler and a way to support a person’s natural action. Instead, this is governance from an “us vs. them” perspective.
- A First look at IronRuby - Microsoft’s venture into Ruby looks pretty good so far, and the plan to move IronRuby into Rubyforge is worthy of applause. Tactically, I am still trying to wrap my head around this Dynamic Language Runtime (DLR) idea and it’s place on top of the .NET Common Language Runtime (CLR). Is it just a deferred compilation model? If so, is that really dynamic? Maybe I am missing the point, but I am having a hard time finding a good summary of the inner workings of the DLR. If anyone has anything, please send it my way.
- All models are wrong, some models are useful - A true statement, and the extension of this maxim to include communities is correct as well. When we worry less about “correctness” of the community, its makeup and its work and more about gaining value by creating value, we succeed, I think.
|
|
|
|
|
|
