Agile Enterprise Architecture

Rice Bowls Full of Data

2009-11-20T08:15:00.000-08:00

It's certainly been a while since I last posted something but, that's what happens when life and work get really busy. I've been trying to shoe-horn an Enterprise Information Management framework (MIKE 2.0) into a Command and Control (C2) environment. It's certainly been a challenge.

The first challenge I had to face was trying to convince a group of entities that there is a difference between information and data. More importantly, that information is more important than data; data management is a subset of information management, not the other way around. That position almost got me lynched. Some time last century when I was actually paying attention in an middle school science class, I learned that information was synthesized/derived from data and was easily interpreted by humans. Then in highschool, it became pretty obvious in that first computer science class that information needed to be decomposed into data so it could be manipulated and stored in a computer.

Simple, huh?

Apparently not.

As with most enterprise architectural conundrums, the problem was neither hardware or software, it was wetware. I dared move the rice-bowl of a 40-year-old empire that only cared for data and cared little about why. When dealing with this group, one observation that I made is that specialization impedes innovation. It may foster optimization but, there is just no room for travel outside of the pidgeon hole.

Security: Show Me The Code

2008-11-13T09:35:00.000-08:00

This seems to be a recurring theme, lately. I'm one of a team of dozens working on a large project and we have a handful of "security professionals" assigned to the team. We have just finished writing a design document and the security section is just huge; directly proportional to the number of people working on it. Anyhow, a bit of stage setting is necessary. I'm participating in a conference call, we have webex running and a collaborative whiteboard plus document sharing.

Me: "This is a big section on security but, it's not complete."

Security Professional: "Oh, what's missing?"

Me: "Software security."

Security Professional: "What do you mean, there's a whole section on how to configure each part of the software stack!"

Me: "No, I meant the software itself, especially the custom software that will need to be developed."

Security Professional: "As long as it's configured properly ... blah blah blah"

I cut/paste a snippet of code for a SQL injection attack onto the whiteboard.

Me: "How do you detect and prevent this?"

Security Professional: "What's that?"

Me: "Code for a SQL injection attack."

Security Professional: "Oh, I don't know anything about that type of security."

Me: "Security isn't a black box."

After that, I let the silence speak for itself. I recommended that as a start, they visit John Viega's outstanding contribution to the security community and re-visit their section of the document.

Money Saving Tip #1

2008-11-11T11:24:00.000-08:00

The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it! Please note, I'm an enterprise architecture consultant.

I was on a sales call the other day and we were chatting with our prospective customer about IT strategy and they wanted some help defining and describing their strategy and lots of help with enterprise architecture. When I asked them where they were in the process, they replied that they were just starting to document the as-is architecture and were following the classic path of as-is, to-be, gap-analysis, etc. and wanted to know how we could help them out. I replied that they needed to choose one of two answers, either the consultant-as-staff-augmentation or the consultant-as-adviser model. When asked what the difference was, I replied "Several hundred thousand dollars."

Naturally, they wanted the less expensive option and I stated if that were really what they were interested in, why do they want to start the process with the as-is architecture? Instead, they could save a truckload of money by starting with what everybody wants to know, the to-be architecture.

You could have heard a pin drop if if were not for the furious typing of the sales rep sending me some rather unflattering IMs questioning my sanity, legitimacy, etc.

"You mean we should not take a comprehensive approach?" asked the CIO.

"Let me put it this way," I replied, "when you go on vacation do you start with a complete survey, inventory and appraisal of your house?"

"Of course not," replied the CIO, "but you didn't answer my question."

"Well, you actually asked 3 questions," I countered. "First, start with your target and then work backwards. Second, only go into as much detail as necessary to make substantial progress. Third, this is unlike most other approaches but unlike others, it won't have the same high chance of failure."

"Thank-you very much, you have given us a lot to think about," was his response.

Much to the shock and surprise of the sales rep, we have been invited to attend some in-depth discussions with several other team members and stakeholders. I anticipate having a discussion about tools, approaches, etc. that will look a lot like this thread in the Enterprise Architecture Network.

Once again, that money saving tip is: "The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it!"

Process vs. Product Quality

2008-10-13T15:04:00.000-07:00

I just finished having a short, hallway conversation with some of my colleagues and it's worth sharing. I was on my soapbox about process quality vs. product quality and I recalled one of the other places I have worked at. It was a matrix organization with a CMMI Level 5 rating, however, we only had a marginally better project success rate than the industry average. I recalled this to my colleagues and asserted that even back at a previous employer, we were CMMI Level 5 because we always made the same mistakes, consistently. Even better, no matter which people we swapped into or out of the process, we still made the same mistakes.

It's perfectly feasible to have a high-quality, consistent GIGO process. Where's the value in that?

IV&V

2008-09-26T00:15:00.000-07:00

I had an opportunity to meet with Mike Rollings of the Burton Group the other day and had a very interesting conversation, touching lightly on several topics.

Regarding enterprise architecture maturity models, he agreed that every model that is currently available is either wholly or largely process-centric and in most cases is not what customers want. They want a quality-based, more tangible maturity model. As a consultant, when I get asked to perform an architectural analysis, the questions my customers inevitably want answered include what's working (and how well), what's broken (and how badly), what can I salvage, what can I exploit, what do I toss, what can I buy, what do I have to build?

Regarding enterprise architecture frameworks in general, he noted a distinct lack of pragmatism in many of them. He agreed that the various framework stewards, including the Open Group, are confusing comprehensiveness for consumability. I wondered aloud if the current frameworks are really being shaped by the (in)ability of the current suite of vendors to implement various, pragmatic facets.

Without answering my question about frameworks, he commented on the almost ubiquitous frustration most enterprise architects have with the existing tools. I'll take that as a diplomatically indirect answer. My major complaints about existing tools are threefold. First, they don't allow complete round-trip visibility from business idea to production. Second, they fall apart when trying to model systems-of-systems. Third, they are built for the needs of modelers, not the needs of the end-customers who need to understand the models. Hmm, just like most of the EA frameworks. Notice the link?

I wanted to chat about business processes, security and the malleability of architectural models but, we ran out of time. It's always good to get some independent validation and verification of one's sanity from a fellow practitioner. Hopefully, we can continue this conversation in the near future.

Security Professionals and Software

2008-09-22T09:35:00.000-07:00

James McGovern simply confirmed what I have observed all along:

I then asked, how many of them actually had a software development background and pretty much every single hand in the room dropped.

This is why we, who do have a software development background, pretty much discount just about everything "security professionals" say. Not only are the overwhelming majority of "security professionals" ignorant of software development and actual code, they seem to be intimidated by anything that's not sold in a black box that they can push buttons on.

Instead of focusing on what not to do, perhaps they should start focusing on how to do something securely. And at the very least, learn enough SQL so a properly parametrized query can be illustrated on a whiteboard.

I have yet to come across a "security professional" I can't send packing after speaking 3, simple words: "Show me code."

TDD and Meaningful Requirements

2008-08-11T11:37:00.000-07:00

Both Craig Brown and Richard Puttick were kind enough to comment on my previous post about meaningful requirements. The post is an extension of a conversation I was a part of with Robert Martin several years ago about Test-Driven Development. The group quickly concluded that unit tests were essentially executable specifications, provided that things like boundary conditions, known negatives, etc. were also fully tested. By extension, user acceptance testing (UAT) were effectively executable requirements, provided that they were tested with the same comprehensiveness as unit tests should be conducted.

Going just one step further, it should be pretty clear that in UAT, not only can the functional expectations be specified in terms of tests and measured against the results, the operational expectations can also be specified in terms of tests and measured against results. These functional and operational expectations are nothing more than functional and technical requirements, both of which can be tested at the same time. This also leads to practice of combining functional and technical requirements into the same statement, which also aids traceability.

We have needlessly complicated our lives and increased opportunities for defect injection by separating functional and technical requirements. A demonstrated good practice, TDD, clearly illustrates how the separation of functional and technical requirements are not only a worst practice, it's not necessary at all.

Enterprise Architecture Maturity Models

2008-08-06T13:34:00.000-07:00

There must be some kind of thread about maturity models crossing the LCD panels of enterprise architects this week. I was again asked for an EA maturity model. I reflexively reached for a couple of the already published maturity models, stopped myself, and asked the question, "EA the noun or EA the verb?"

Apparently, the customer would like an assessment of the maturity of their enterprise architecture, the noun.

This is actually more of a challenge since almost all of the maturity models out there are process-oriented, not product oriented. CMMi is a perfect example. CMMi is product and quality agnostic. GIGO. It's completely possible to build CMMi Level 5 compliant lead-lined lifejackets. The same goes for just about any other process-based maturity model. Not very helpful when the only thing that really counts is the quality of the results, a fact most process weenies seem to forget (or overlook because that's really hard work). Of course, almost all of the EA maturity models (NASICO, Open Group, EAMMF, etc.) are either direct adaptations of CMMi or embed a lot of CMMi in them.

I was pleasantly surprised to find the E2AMM. It didn't surprise me that it's out of Europe at all. The Europeans are so far ahead of the Americas (both continents) in terms of EA it's almost embarassing. No, it is embarassing. Anyhow, I'm going to take a close look at this model to see if it is applicable to this particular customer's needs. I'll post my observations here, later.

SOA Governance and Vendors

2008-08-04T13:23:00.000-07:00

We have seen a bit more consolidation in the SOA components arena again, with Iona and BEA getting swallowed up. I didn't use the term "products" because as we all know, it's not possible to go out and buy a SOA, in spite of all the vendors would have you believe and many corporations and agencies hope for so they can spend year-end cash.

Of course, the same goes for SOA governance, which can't be bought, which Michael Stamback reminds us of. Well, he reminds us of that in his first tip. As for the other 4, let's just see ...

Tip #2: Look for a vendor that can explain how their technology is applied

Ah, and I had such high hopes. At least he could have waited until the 4th or 5th tip to steamroll his own advice. He must be pretty new at this schtick.

Tip #3: Beware of the kitchen sink!

This is great advice from a vendor who just loves to sell the kitchen sink. They re-sell Systinet's (wait, Mercury's .. wait, HP's) product last time I looked. You will probably be better off talking to HP directly and get the story from the horse's mouth. Then again, in terms of SOA components, they now have 2 kitchen sinks to sell, though the home-grown one really never worked and BEA never had any SOA components related to governance.

Tip #4: Start small and expand

Can't argue with that one. Governance tools beyond a whiteboard, post-its and a spreadsheet aren't necessary until you have about a dozen services and at least one is composite. Until then, there's really no SOA; barely a collection of services, really. Then again, who's to argue with someone willing to throw money away?

Tip #5: Look for an integrated solution

Ah, I just love this one. Even back when I participated in an evaluation of all the various governance "solutions" out there, only 2 vendors had an integrated stack (Amberpoint and SOA Software) and only one had a comprehensive run-time offering (SOA Software). I don't see how the landscape has changed, at all. The others may claim to have an "integrated" offering. Well, if a colloid is considered integrated, that's fine.

Of course, none of these folks go down deeper into the stack and deal with how to create, manage and enforce governance policies for the rest of the SOA stack outside of the service, like the service container itself! Then again, that's a really hard problem to solve and of course, you can't sell what you don't have a solution for, right?

Meaningful Requirements

2008-08-01T08:59:00.000-07:00

I simply have to comment on James McGovern's latest post on requirements where he says:

When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?

This is the result of failing to realize that "technical requirements" cannot be made separate from functional requirements since a function includes the notion of acceptable/predictable behavior. This is where the analysts can borrow a technique from developers: Test-Driven Development (TDD). For lack of a better term, let's call it Test-Driven Analysis.

What would TDA include? It would include a description of the function plus sample inputs, outputs and expected results, including expected failures (samples of say, SQL injection attack code that must be rejected). Moreover, this wouldn't just be data-focused. Other properties such as the range of acceptable response times, expected feedback, etc. need to be determined. Now we have embedded those "technical requirements" directly into the functional requirements plus have added measurable quality attributes that further serve as acceptance tests/criteria.

It's not like this can't be done, it's just a lot of hard work.

Paint Yourself Into The Corner pattern

2008-06-04T10:10:00.000-07:00

Here's how it works. Typically, a new CTO or CIO gets hired/promoted and after a couple of days declares that, "We are now an 'X' technology/platform shop."

I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first. This is similar to the "Fire, Ready, Aim" pattern. It starts out with a CTO (or CIO) declaring that a certain technology or platform is the new standard before understanding what all of the problems are. This decision is usually made on the alleged cost savings to be achieve through standardization, alleged efficiencies to be achieved by having similarly skilled staff in a matrix organization and is largely based on the CTO/CIOs own past skill set (familiarity). Sound stupid? Well, it is. However, why do I see it happening all the time? I've seen people put more thought into what kind of car they want to buy than the time they spend figuring out what types of technology are best for their business.

Enterprise, or any other kind of "technical" architecture is not all about technology. CTOs in particular often forget this. Architecture is about devising manageable solutions that will actually get used to solve specific business problems. It's not about "simplifying" the toolset to make the tools more manageable! Some of these solutions will be very complex but, complexity can be managed. Managing complexity can also be applied to the toolbox.

Tired of The Same Old CRUD?

2008-06-03T08:31:00.000-07:00

One of our customers has a very large robotic storage system and we have been asked to propose a new control system. This meant I needed to do some research and dust off some very old skills. I have always seen robots and software agents as cousins. As I was doing some research, a few patterns started to emerge ...

The first time I had a chance to program (virtual) robots was back on an Apple II with a game called Robot Wars. That may seem pretty humorous but, it taught some difficult lessons: real-time systems, event queues, interrupts, and programming on vastly resource-constrained systems. The developer only had 256 lines of code in which to build their virtual robot. Little did I know at the time this was actually a reasonable training ground for learning how to write embedded systems.

Then, several years later after the PC was invented, Crobots was released, that opened up some more possibilities but robots were still limited to 1000 instructions. There were legions of budding developers and engineers at campuses around the world designing virtual battle-bots.

C++robots broke that 1000 instruction barrier, 10 years later. I don't know much about the evolution of the Crobot genealogy because by the time C++robots came along, I had picked up this new language called Java.

Since we just love re-inventing the ~~wheel~~ robot in this industry, a decade after Crobots some Java devs at IBM were helpint to create Robocode as a way to teach the Java programming language. This turned out to be extremely popular and even spawned international robot leagues. Robocode grew to be very sophisticated, very quickly, including technologies such as swarm intelligence, blackboards and even genetic algorithms. This is very similar to the types of technologies being embedded into software agents for tasks like remote monitoring and supply-chain optimization.

In what appears to be more deja vu, Microsoft has recently released RoboChamps featuring their Concurrency and Coordination Runtime plus the Decentralized Software Services. Why is this important, you ask? Well, most importantly, it's a way to learn about concurrency and distributed systems without killing anybody! Mistakes are safely made in the virtual arena. It also shows a degree of maturity in the .Net platform if it can now be used to solve some of the more difficult computing problems out there.

Anyhow, back to the patterns. Aside from the obvious (4 virtual robot games), I delved into the bios of the authors of RoboCode and RoboChamps. The source of the patterns quickly emerged. All of the authors have substantial and impressive backgrounds in distributed systems, autonomic computing, software factories and a bit of AI. What are some of the major patterns here?

1) Programming robots is a fun way to learn a new programming language
2) Robotics is hard work compared to a web-app
3) Robots have contracts and SLAs with their operating envioronments
4) Robots are autonomous
5) Robots can be employed in co-ordination with other robots to perform more complex functions (loosely-coupled, composition, aggregated processes)
6) Robots can work in parallel (linear scalability)
7) Robots are to a large degree, event-driven

Hmm ... this smells a lot like a service in a SOA, doesn't it?

"Getting" the Business Means "Get In" the Business

2008-04-24T16:18:00.001-07:00

It's always fun visiting the customers at their own workplaces. What takes an hour to describe can instantly be seen; the proverbial picture that's worth a thousand words. I was out at a customer site last week and noticed a very depressing ritual that I have seen many times before. Here's how it goes ...

The consultants are brought in to solve a problem;
The business users are excited that, finally, something is going to get done to fix the problem;
The problem is discussed, a couple of quick suggestions and concepts are described and the business users are enthusiastic about the possibilities;
The business users ask, "So, what are the next steps?"
The IT manager says, "Well, we need to gather the requirements."
The business users physically roll their eyes and slump back in their seats in anticipation of another snail-paced, IT boondoggle.

Here is a very, very important lesson every technology consultant needs to be mindful of: The biggest barrier to your success as a consultant is the technology organization you are there to help/support/augment.

This isn't about folks in IT not having ever learned how to read a balance sheet or other such easily learned knowledge. This also isn't about understanding the basics about how their employer actually makes money and who the customers are. This is about being able to put yourself into the shoes of the people who actually use and need the products and services you provide/build. This is remarkably easy to do.

The key to "getting" the business is to "get in" the business. In this particular case, I had spent a significant chunk of the day on the factory floor observing how people actually accomplished their tasks, complete with impediments, workarounds, frustrations and pride. No requirements document would ever be able to describe the environment and conditions under which the tasks needed to be completed. They would only describe what the user interface was supposed to do. Hopefully I will return in a few weeks where I will resume gathering requirements from the factory floor.

That's right, turn off your computer, put down your whiteboard markers, leave that sterile ivory tower and get onto the floor or out into the field!

Sale or Adoption

2008-04-02T13:58:00.000-07:00

James McGovern talks about failing to sell A/agile in the enterprise. While close, I believe the sales process is not at fault, rather, it's that path to adoption. Also, along with everything else, it's all truly about alignment with the business goals and strategies.

I've recently had the benefit of seeing the life-cycle of almost a dozen agile software development projects over the past year, some ranging through multi-year efforts. I have seen the victories, the failures and the in-between. I started noting some contradictory behavior between customer needs and agile practices, especially the more dogmatic ones. However, I didn't have sufficient data to make any good correlations.

One particular incident involved Test-Driven Development (TDD). In this case the dogma stated that TDD must be done. However, it was truly placing the delivery schedule in jeopardy. Moreover, the deliverables only needed to be good enough. Needless to say, a large rift developed dividing the dogmatics and the customer. Thankfully, the customer's needs prevailed and TDD was tossed and the product was barely delivered in time. This is only one such incident but, clearly the whole concept wasn't working as advertised.

A couple of weeks ago, I stumbled across this paper about software process adoptions. 7 years ago, someone has already thought through this. Bringing back the TDD example, trying to apply a technique that emphasizes quality when the real strategy is innovation (where customers willingly trade quality for newness!) is completely counterproductive. That is, avoid prescriptive processes that require discipline when quality is not the business strategy. Clearly, no matter how hard we try to sell agile, we will fail. Why? There is no logical path for adoption.

Don't sell agile!

To quote a colleague, "Nobody buys Toyota trucks because of the TPS and lean manufacturing."

Technical Requirements

2008-04-02T13:40:00.000-07:00

Simon Brown was kind enough to comment on my previous post and said,

"I'm trying to tackle the other (easier?) problem of when technical people don't even think about NFRs. First things first, we need technical people to understand why NFRs are important."

There's a very simple way to get technical people to understand why technical requirements are important. They must be clearly and logically linked to delivering a functional requirement. Go one step further and simply remove the distinction between functional requirements and technical requirements by stating how a functional requirement must be delivered in terms of quality-of-service or a service level agreement. An example:

"The customer must be able to securely submit the final order plus payment details and receive an acknowledgment via both email and a following web page in under 10 seconds."

Separating technical and functional requirements makes it all too easy to make the former into an afterthought.

Non-functional means it doesn't work!

2008-03-21T09:00:00.000-07:00

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. One of the many attempts made by architects to provide these guidelines is the software architecture document. Simon Brown blogs about another attempt that is probably doomed. Just looking at the document structure, the non-functional view is 4-5 times larger than the functional view.

What does the customer think non-functional requirements mean? No, it's not just semantics. I vividly recall an RFP-response drafting session I was a part of, many years ago. This was the first time I had participated in a fairly large team responding to a multi-billion dollar opportunity. I had finished up one sub-section, and handed it over to my boss. Without raising his head, he took the doc and with his red pen, crossed out every single instance of "non-functional" and handed back the draft to me and said, "The customer doesn't want to pay for something that doesn't work."

Of course, in geek-speak, functional and non-functional have a very specific meaning. In standard, workaday English, functional means something works and non-functional means something doesn't work or is broken. Why then, do we architects pay so much attention to designing software that doesn't work?

If we want all of those architectural "ilities" to be accounted for and truly guide the design/construction of systems, we need to immediately start doing 2 things:

1) Start calling them technical requirements and/or constraints.
2) Directly map them to functional requirements by defining the operational characteristics the customer wants each feature to provide.

Every, single functional requirement should explicitly be able to describe just how much of each "ility" needs to be built, thereby preventing over/under-engineering. This embeds the success measurement criteria for every, single feature!

Maybe we need to start talking about measurement driven requirements (MDR)?

SOA Is Not Enterprise Architecture

2008-03-14T09:31:00.000-07:00

Yet one more person is writing about people talking/writing about the equivalence of SOA and enterprise architecture.

A SOA is one of many possible implementations of an Enterprise Architecture. SOA is not enterprise architecture. More often than not, a SOA will need to co-exist with other architectures in a more comprehensive enterprise architecture.

Sorry boys and girls, EA just isn't that easy.

No BDUF != NoDUF

2008-01-22T14:08:00.000-08:00

Continuing with the theme of architecture in an agile organization, one of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF).

No BDUF does not mean NoDUF!

NoBDUF != NoDUF

I submit that every single one of us is guilty of designing a solution to a problem before the person is finished describing what the problem is! Anybody with a modicum of imagination does design up front (DUF). In my experience, the amount of ceremony required for DUF is directly proportional to the cost-to-fix/cost-of-failure. This is pretty obvious in the construction of physical objects, and the debt is tangible. I don't think it's unreasonable to apply the same rule of thumb to software or virtual objects.

Architecture In An Agile Organization

2008-01-18T14:26:00.000-08:00

Last night, my colleague Chris Sterling gave a presentation about Architecture In An Agile Organization. He raised several points I want to develop over the next few posts.

One of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF). No BDUF does not mean NoDUF!

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. What does the customer think non-functional requirements mean? No, it's not just semantics.

Architecture is not all about technology. I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first.

Requirements are not specifications. Seriously, there is a difference!

Re-cycle the box

2008-01-16T13:48:00.000-08:00

I was in a meeting with a client a while back along with several other consultants from different companies. Once again, the client was having a problem with their databases (of course!). They had several of each: SQL Server, DB2 and Oracle.

I'm rapidly forming the opinion that any consultant who concentrates on Oracle is nothing more than a corporate shill for Oracle. It seems that almost every solution they have to a database problem is to add another database, thereby increasing license fees for the client. Is there some grand, kick-back scheme or something that Oracle consultants get looped into? At least the people representing IBM and Microsoft product lines suggested investigating other solutions ranging from ETL software to messaging to web services. The Oracle guys went right for the throat and declared that yet another intermediate "consolidation" database instance was the answer. What a crock.

I looked across the table at the CIO and said, "If you are truly serious about solving your integration problem, get rid of one of your database platforms. Let them all know that the two who work together best get to stay." I also reminded him that the company owned all the tools they needed to solve the problem so, capital costs should be 0. I'm not sure if he is going to follow that strategy over the long term but, I certainly know that my suggestion kick-started some very, very creative and resourceful thinking amongst the other 3 groups of consultants!

Which Conference?

2007-10-05T11:01:00.000-07:00

I'm in the process of creating my budget for 2008 and I was hoping to solicit some advice and opinions from my readers. I essentially have 2 questions:

1) Aside from the obvious opportunities for socializing, is attending an Enterprise Architecture conference valuable?

2) If it is valuable, which one to attend?

What I'm looking for is a conference with good case studies, in-the-trenches anecdotes and enough visionaries to give me some idea of what I'll be up against over the next 5 years. A good balance of business and technology would also be good.

Wasn't There A Commercial About This?

2007-06-20T13:35:00.000-07:00

As a customer, I was so impressed with the quality of their work, I joined their company!

Departing my previous employer certainly wasn't an act of prescience, since the undercurrents of certain trends always rise to the top in public companies, it's just that the public is the last to know. From my own perspective, my work there was just one more experience that further convinces me that the practice of enterprise architecture needs to be completely divorced from the IT function in order to be effective. Moreover, enterprise architecture must be seamlessly integrated with a mature, portfolio management practice in order to provide the business stakeholders with the degree of insight and transparency it needs in order to make timely and accurate business decisions.

Anyhow, I now have the opportunity to not only help make this enterprise agile through architecture but, I can help others through leading by example.

Un-Open Open-Door Policy

2007-05-24T13:53:00.000-07:00

Have you ever noticed how corporate-speak can completely rot a manager's mind when they start to believe their own words? The oxymorons and contradictions just start to grow as fast as kudzu. One of my colleagues recently met with his new manager and hastily scribbled down the following quote:

"I have an open-door policy ... but just because my door is open doesn't mean it's OK to come in and talk to me. Schedule an appointment, first."

Of course, this same manager's calendar is always blacked out as "busy" throughout the whole day. It's like the fellow just switches on the "auto-cliche" mode when he walks into the door in the morning. Worse yet, he only has 6 direct reports and he has aspirations of injecting some agility into the SDLC. Clearly a classic example of management-by-in-flight-magazine (mbifm) or hamburger management.

Enterprise-Speed Blogging

2007-05-21T10:35:00.000-07:00

About 1.5 years ago, a tiny group of ~~dissidents~~ visionaries (the victorious get to re-write history) established a stealth wiki and also started using it's blogging capabilities. This was only the first. Exactly a half-dozen of us have been continuously blogging, internally. Apparently it was a shock to some internal auditors, lawyers, HR and senior execs when they had the ~~original~~ idea of setting up an internal, corporate blog, that one already existed. To their credit, they didn't shut down the stealth blogs.

Anyhow, the point of the post is that it took the enterprise about 1 year from idea to roll-out. Aside from the obvious conclusion that most enterprises are as agile as a cow on skates, the fact that it took people in the enterprise a year to overcome FUD, find/allocate resources and devise a management scheme for a non-revenue-generating internal resource. All this for a simple piece of blogging software that I'm sure any of my readers could have set up and running in an afternoon. That's all the time it took us to set up the original wiki and blog, too. Getting the installation officially blessed took the other 364.5 days.

Proponents of open-source software, Ruby and other dynamic languages, methodologies, etc. need to take into account it takes time to overcome FUD even in light of working proof.

Architectural Role & Career Progression

2007-05-18T11:01:00.000-07:00

Simon Brown has started an interesting discussion about career paths for architects. To code or not to code is one of the thoughts, as is the timing of architecture transitioning from being technology-oriented to business-oriented. Business-Oriented Architecture (BOA), anyone?