“Generative” EA Principles

by | June 27, 2009

In my previous post, I suggested that integrating Kevin Kelly’s 8 “generatives” will help EA adoption (please read Kevin’s excellent article Better than Free for the details on each):

  • Immediacy
  • Personalization
  • Interpretation
  • Authenticity
  • Accessibility
  • Embodiment
  • Patronage
  • Findability

This really got me thinking about how we approach introducing and maturing enterprise architecture in our organizations. How many of you made attempts to introduce EA practices and struggled in your organizations?  What  attracts clients to your EA service? Do you use a carrot or a stick? Why would people in your organization come to you for services? What makes your service better than free?

Can we take Kevin’s “generatives” and apply them as principles of our EA practice? This post describes how we can apply Kevin’s “generatives” as influencing guiding principles for delivering Enterprise Architecture.

Immediacy – Does your EA practice provide immediacy to facilitate solution delivery in your organization? Can your EA serve to deliver solutions quicker and in a supported, sustainable manner?  If your EA process takes weeks or months or even years, there is no immediacy for your clients and they will go elsewhere even if it costs them more. If we design our EA services to address the immediacy demand of our clients, we can deliver the immediacy generative. Applying our EA Guiding Principle “Reuse-Acquire-Create” will help.

Personalization – Does your EA practice address the requirements of your client’s specific needs? Communication is a key role for an Enterprise Architect. Building relationships and creating value for your clients by understanding their needs and enabling solutions tailored to their business challenges. This creates “stickiness” between the business and your EA practice. Both parties collaboratively build a relationship which is a generative asset that they are invested in. To me this is a great way of thinking about technology services becoming a trusted partner to the business and delivering the personalization generative.

Interpretation– Can your EA practice be the interpreter and bridge between easily accessible technology solutions and real business requirements?  How many times do business units in your organization buy a technology to address their current pain point ,only to find that the technology is cheap to acquire but costly to implement and difficult to  integrate? If we as EA’s, can help our business partners make better choices by guiding them with standard solution architectures that integrate into our overall enterprise architecture, we meet the interpretation generative.

Authenticity – Do the solutions proposed by your EA practice provide a total solution that addresses implementation and ongoing service delivery at a fair price? We need to build the Business Architecture layer of our Enterprise Architecture.  By understanding the business processes and cycles, we can tailor standard solution architectures that integrate people, process, information and technology. By putting the business needs ahead of technology acquisition, we can deliver the authentic generative.

Accessibility – How do we make EA accessible to our organization? Create a model for your clients to understand the levels of technology governance.  We built a model that describes technology governance based on 3 axes – funding, impact and support.  The scales for these factors range from centralized to decentralized.  By combining these factors, we articulate 4 governance groups – enterprise, departmental, innovative and opportunistic. I will describe in more detail about this in a future post. Ensuring that our clients understand what it takes to adopt a technology to provide service based on budget, impact and support factors, delivers on the accessibility generative.

Embodiment– Kevin talked about music being free but the live concert performance being the thing with value.  For EA, my analogy would be doing EA documentation to the “excruciating level of detail” that John Zachman advocates, while it is not free, it also does not deliver value.  Documenting our architecture at a level that provides value and allows maintainability, enables enterprise architects to focus on delivering the EA practice. The value (embodiment) of EA artifacts is not in the creation of them but in the leveraging of them to build well integrated, reliable and resilient architectures.  Leveraging IT Service Management practices like ITIL also help deliver the embodiment generative.

Patronage– If people are willing to pay creators for work of value, what is our analogy for enterprise architecture? Since we started our EA practice, we worked hard to become the valued and trusted partners of our clients at the Institute. How do we build trust and encourage our clients to seek us out?  Building solid processes to capture client needs, assess them quickly and deliver a response timely will help us move to a partnership model that delivers work of value. Recently, EA reviews have been put in place for all purchase requistions for new software. Ensuring that we do these reviews quickly and communicate back to our requesters is essential to build on the level of trust shown us. In this way our EA practice can deliver the patronage generative. 

Findability – In the world of freely available technology, how do we provide accessibility to our EA services? What communication methods and techniques do we need to create to allow our services to be found.  Obviously, we need to create a web presence, an artifact repository, an entry in our Core Service Catalogue and it goes without saying communicate, communicate, communicate.  This aggregate generative puts all the other 7 generatives together in a cohesive package and can make your EA service “generative”.

If applications, services and technology are freely available in the cloud, why would our clients come to us? What can we create in an Enterprise Architecture service that is immediate, personalized, interpreted, authentic, accessible, aligned, appreciative and attributable?  I hope I gave you some ideas and answers in this post.  I look forward to your comments and feedback.

4 thoughts on ““Generative” EA Principles

  1. Johan Lindberg

    Hi,

    It is indeed an interesting idea to apply these principles to EA. I am, however, not sure if I think they are all relevant (immediacy and authenticity seem out of place). They were, after all, constructed for “products” rather than “processes” which, at least in my mind, is what EA is all about.

    Embodiment however is a very interesting principle that I believe is too often underestimated. It made me think along the lines of evangelism and the importance of communication, communication and communication. It’s one thing to produce a well written report and another thing entirely to communicate it such that others (non-architects) understand it and can act on it.

    If embodiment in music is live performance, it is meetings, presentations and workshops in EA. And, of course, it doesn’t stop just because a decision has been taken which is why I’m very happy to see you mention IT Service Management here. Too few architects follow through into the rough waters of operations.

    /Johan

    Reply
    1. LeodeSousa Post author

      Johan, thank you for the feedback. I was trying to fit each generative into an EA context and might have missed on a couple. Thank you for pointing out that the meetings, presentations and workshops are EA embodied. I started my career in IT as a mainframe computer operator so the operational side is a persistent theme in my EA thinking. Cheers! Leo

      Reply
  2. Johan Lindberg

    Hi again,

    Re-reading my comment after a good night’s sleep I’m noticing that I shouldn’t have used the word “relevant”. I still think that some of these principles don’t fit very well but I do think they are all relevant to talk about in an EA context.

    Immediacy, for example, is becoming more and more expected in an increasingly cloudy world and at the same time “transaction costs” of getting things done is becoming larger and larger. People deciding on COTS/SaaS projects usually (at first) expect something up and running in a few weeks and the (surprising!?) reality is that most IT departments require months if not years to deliver expected functionality. At least if we’re talking about core services in a company that has an IT history.

    I think it’s a response that is caused by frustration and a lack of understanding of how things fit together in an ever more complex IT operations environment. EAs are probably those best equipped and positioned to bring clarity to these issues but few seem willing to do so (at least where I work).

    /Johan

    Reply
  3. Alec Sharp

    This was a great post, Leo. It hits the essence of what we want from a great article or blog post – it simultaneously informs, and stimulates thought. Certainly I was informed by learning about Kevin Kelly’s generatives, and especially by the thinking behind this viewpoint. It was a major relief to read a credible position that in the age of “everything is free” there are still differentiators that are only available if you engage the real deal.
    Applying Kevin’s generatives to EA was a great idea, and I instantly related to two of your interpretations in particular – immediacy and patronage. Whether I’ve been working on Data Management or Business Process Management or Business Architecture, I’ve found that a key to success is always to find a way to deliver value in the short term while laying brick for the long terms (immediacy.) That segués naturally into the idea of patronage – someone has to care enough about what you do to be your patron. Without these two, my experience is that you’re hooped.
    Looking forward, I’m really interested to hear what you have to say about Accessibility. Your model, which involves 3 axes – funding, impact and support – sounds very practical, and very interesting.
    Can’t wait to read what you have to say about this.
    Cheers,
    Alec

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.