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.
