About Me

I am a Principal Enterprise Architect for Evernorth, enjoying working making healthcare more predictable, affordable, and simple. Over my 20+ year career, I’ve practiced EA within many different business areas including healthcare, insurance, publishing, agriculture, travel & leisure, and financial services.  I started out my career as an application developer, with interests in user interface design, human/computer interaction, and distributed application design. I received my bachelor’s and master’s degrees from the University of Illinois at Urbana-Champaign.

Feel free to drop me an email if you’ve got questions. My email shouldn’t be too hard to figure out from the domain of this blog.

Publications

  • SOA Governance, published by Packt Publishing in 2008.  I’m still surprised to see a couple of dollars in royalty payments trickle down each quarter this long after it was published.

Quotes

Podcasts

Presentations, Webinars

  • Panelist, Oracle OpenWorld, “SOA Governance for Architects,” October 2009.
  • Panelist, Gartner Enterprise Architecture Summit, “EA and SOA,” December 2008.
  • Presenter, SOA Consortium Meeting, “SOA Governance,” September 2008
  • Panelist, Gartner Enterprise Architecture Summit, “EA and SOA,” June 2008.
  • Panelist, Gartner Application Architecture, Development, and Integration Summit, “Measuring the Value of SOA,” June 2008.
  • Panelist, Gartner Enterprise Architecture Summit, “EA and SOA,” December 2007.
  • Panelist, Gartner Application Architecture, Development, and Integration Summit, “Funding SOA,” December 2007.
  • Panelist, The Open Group EA Practitioner’s Conference, Future of SOA, July 2007.
  • MomentumSI/IBM DataPower Webinar: Power of Policy-Driven Infrastructure, July 2007.
  • MomentumSI Webinar: Successful SOA Pilots, February 2007.
  • Burton Group Catalyst Presentation: Convergence of SOA Infrastructure, June 2006.
  • Panelist, InfoWorld SOA Executive Forum, SOA Governance, March 2006.
  • IQPC: Practical Steps to Successful SOA, October 2005.

Interviews

Places

Here are places in the US that I’ve visited. My criteria for “visited” typically means that I’ve spent a night in a hotel in a city in that state and done at least a little bit of exploring. I’ve driven through a few more of these states, had stopovers in airports, etc. but that doesn’t really count.
create your own personalized map of the USA
or write about it on the open travel guide

One Response to “About Me”

  • Dan:
    April 29, 2012 at 5:45 pm

    Enterprise Architecture is best “practiced.” Since there is a fundamental conceptual component to EA, that can be a problem. If you start from the top, you will have the problem of engagement of technologists, of synchronization of vision with IT Initiatives. If you start from the bottom, you must serve the day to day engineering needs while convincing IT management engineering is not enough. I think the most effective approach is to work from the middle, from a place where the enterprise is feeling pain (loss or need to respond to events)–where executive management is actually paying attention to something “exceptional” they must change.

    That is a fairly broad band of organizational territory extending from engineering functions in IT to process management functions in “the business.” The key is to build consensus 1) there is a problem that must be solved; 2) quick, short term fixes are not the solution, nor do they have to “boil the ocean” to see improvement; 3) that the pain is symptomatic of loss of adaptive capability that made them successful in the first place; 3) that adaptive, incremental approaches will restore that strength.

    This middle band transmits the “will” of the business to the capabilities that execute business value and accommodates the business to the technical realities it can reasonably have. The Venn diagram that has people, process, and technology overlapping doesn’t quite state the primacy of people at the intersection. It is always people that regulate what happens, set/don’t set expectations, and make decisions about technical and process capability “fit and fitness” (as you say).

    All forward progress/diversion is measured by people, for people. The EA Team must therefore be the “core” of a stewardship web that shepherds the way forward on a consistent path. This means it is not the EA “Program” or “Process” that guides the enterprise. And the latest technology vendor pitch can never be the “answer to all the dreams of the enterprise.” This “extended EA team” (and I would include business stewards) must be the author of reference models and architectures that define those “dreams” (aka To-Be/Target) and the means to get there (aka Roadmaps…). They are also the curators of the As-Is/Current (aka, “that which must not be screwed up in the process”)–because as you “get there,” that’s where you will be, and you want to be in a stable place!

    This means architecture process should be “lite,” your artifacts should be collaborative results, and they should be readily understood by senior management. The extended team approach also means there should be constant awareness within the broader enterprise of its presence and intent.

Leave a Reply

My Book

Publisher's Page

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.

Contact Us | Terms of Use | Trademarks | Privacy Statement
Copyright © 2009 Todd Biske: Outside the Box. All Rights Reserved.