Enterprise Architecture: From Incite comes Insight...

Isn't it fascinating how procurement departments negotiate enterprise agreements without an understanding of the roadmaps or even the unarticulated strategic direction that enterprise architecture team wants to drive towards...



Many software license agreements are not a fit for their intended purpose. Many contracts fail to explain clearly what the buyer has to measure to stay compliant, place unreasonable restrictions on usage and/or deployment and of course can be an impediment to the enterprise taking advantage of cloud computing.

When these two groups aren't communicating, it is guaranteed that this will result in unexpected software costs and audit costs. The communication however doesn't end here as it is important for the vendor to also participate in the conversations. Generally speaking, many enterprise architects ask thoughtful questions of vendors but fail to get how specific scenarios should be handled in writing. Lawyers that work with procurement teams are very good at getting in writing what was agreed if you can explain it clearly with relevant examples. Oral descriptions of policy and promises that "we never enforce that" are insufficient.

Another missed opportunity is for the enterprise architecture team to periodically recheck existing license agreements to see where they may need to be amended. Generally speaking, much of the license renewal ceremony revolves around keeping down costs, but this isn't an excuse to also ask for several new considerations. After all, you are much smarter now than you were when the agreement was negotiated. If the enterprise architecture team isn't providing input, then this is criminal...

Want to find top talent? More importantly, want to know the types of questions I would ask if you had to interview with me? Below are ten questions you should ask of enterprise architect candidates as part of the interview process...



I have decided to make this a two-part blog where the first part is simply to present the questions with a followup as to the importance of them.

1. What type of work do you want to be doing five years from now?
2. Do you think that if the Federal Government had top talent in its enterprise architecture team, would the deficit be lower than it is today?
3. What does work/life balance mean to you?
4. Do you write code outside of work?
5. What was the best and worst software project that you've been part of?
6. What was the defining characteristic of the best and worst boss you have worked for?
7. What would you recommend in terms of enterprise spend for security. Would you target more money for infrastructure or for applications?
8. How should enterprise architects be involved in the pursuit IT outsourcing?
9. What value proposition could cloud computing provide to our organization?
10. Are you on LinkedIn? If so, do you participate in a larger enterprise architecture community?

It would seem to me that if Enterprise Architects wanted to improve the quality of enterprise application development, they would beat their PMO silly with wet noodles for designing processes that allow for the era of silence...



Increasing, many enterprises are convincing themselves that they adhere to Agile methodologies, yet somehow they have simply hijacked the vocabulary of SCRUM and are still waterfall in their approaches. Even for enterprises that are honest enough with themselves and have acknowledged that they can't be anything but waterfall still need to take the next step forward and acknowledge the existence of the era of silence.

The era of silence is the extended period of time, often measured in six to twelve month increments squeezed in somewhere between completing the analysis of user requirements and the big bang testing phase. The era of silence is only broken when discussions betwen development and the customer occurs on the predictable status of the development schedule.

We all know that an enterprise and their PMO organizations love process, but how come we are solely focused on process steps and governance gates at the expense of building better software? Wouldn't it be wonderful if a PMO didn't focus on what artifacts we produced on what dates vs focusing instead on ensuring that large expanses of time don't occur without everyone involved in the SDLC truly collaborating...

Throughout my career, I have witnessed many attempts to govern how enterprise applications are constructed with some being better than others. At some level, I think they are all an absymal failure in that they tend to focus on the process and artifacts over the values that should be held by software development communities...



What would happen if you were to throw out the formalized architecture steering board processes and were to embrace Agile approaches to governance? What would happen if architects and developers coming before your board had to testify publicly that they will adhere to the below values:
We will design and develop enterprise applications that:

• Other developers can easily debug and maintain


• We will create quality documentation that allows for new developers to understand flow and exception handling


• We will increase cohesion and reduce coupling at every opportunity


• Our design will allow for graceful degradation under extreme load


• We will implement and properly leverage Version Control


• Business logic will reside in the appropriate tier


• We will stay as current as possible with patches and vendor releases


• We will achieve balance when it comes to performance, security, usability and scalability


• We will ensure that our application can be and is properly tested even if this responsibility resides in another group

OK, by now you are more than familiar with my rants on the differences between management and leadership and how I hate that many people in IT use these words interchangeably. Another evil is when you hear a PMP certified process weenie refer to their Project Management Lifecycle (PMLC) as a Software Development Lifecycle (SDLC). So today, as a wannabe Gartner analyst, I am coining a new term: Developer Oriented Development (DOD)...



If we are to improve the quality of software being delivered to customers, we must acknowledge that we already have enough focus on tests, metrics and processes but spend way too little time on allowing developers time to write better code. Below is a simple process steps of things you can do to improve code.

1. Allow only talented people to write code. Let's face it. There are people out there writing code who really shouldn't be. They produce bad code and take away time from people who could have written it properly in the first place to have to spend time remediating it. So, let's solve for competence as the first step.

2. Afford talented developers time they need to think about the problem they need to solve. Yes, PMP weenies you need to stop filling developers time with meetings that are nothing more than ceremonial blowhard jamborees. They don't need to hear you read the project charter out loud that you cut-and-paste from another project that came before it.

3. Let developers actually write code. This is the developers way of solving problems. Developers think in code so don't distract them with making them document in some form that is all about others and not about code.

4. Repeat steps 1 thru 3 until done.

I personally guarantee that if an Enterprise doesn't get a 5x factor increase in quality by trying my Developer Oriented Development methodology, I will eat my shirt in front of a large audience at the next Gartner conference...

Frequently, I hear enterprise employees complaining about the lack of quality delivered by IT Outsourcing firms based in India. They always pine on the belief that their CIO doesn't care about quality and is only focused on price. At some level, when the CIO bought into IT outsourcing they had to acknowledge that they were going to use developers with less years of experience and therefore expected a drop in quality. With that being said, I think there are also other factors to be considered...



It is important to realize that normally high quality comes at higher price. But lower quality may increase total costs. The cost of poor quality or service is magnified not only in terms of trying to recover a project that is already damaged, but also in terms of loss of brand equity and trust. After all, the cost of quality is not only the cost of prevention of non-conformance and the cost of appraisal for conformance; it is also the cost of failure to conform.

We have all heard of many failed ERP implementations where companies have expended years and huge efforts to get back on track. In my humble opinion, I believe the challenge is the simple acknowledgement that many aspects of cost are known upfront and/or emerge at a faster rate than issues related to quality. If costs increase in the delivery of an enterprise application, the vendor has to personally bring this to the attention of the CIO. However, if the vendor isn't delivering quality, there is no event that requires the vendor to disclose the deficiencies.

Many IT Outsourcing agreements touch upon quality only through the lens of process. Thou shalt have a code review. Thou shalt do testing, etc. but few if any IT Outsourcing agreements set a measurable standard for quality. If enterprise employees continue to bitch and complain yet won't work towards creating a standard for measurement then they are simply pissing into the wind.

The information security community has figured out the need for standards to cover the application security space where entities such as Open web Application Security Project (OWASP) is diligently working towards developer guides, standards and maturity models. The enterprise needs to borrow from this playbook and create equivalents that focus on quality...

We all know that IT Outsourcing to India can most certainly result in suboptimal code, I humbly believe there is a bigger reason for why code in large enterprises continues to be fundamentally bad...



I believe the Project Management Institute (PMI) is a terrorist organization that teaches non-technical project managers how to deliver low-quality code and that they are the biggest impediment to creating high quality code. Let's face it, the majority of project managers continue to deliver projects over budget and late. This of course starts with bad estimation techniques but almost always concludes with a call for developers to write code quickly and the decline begins.

How many times have you participated on projects where some assclown makes a call to just get it out the door and to leave perfection to God. This usually is done under the premise that if they don't get it out the door, the project may die quickly. In order words, the people who control developers are telling developers that maintainability of code is a second priority. Some PMs though are at least considerate enough to make cordial statements that they will set aside time after the rollout, but we all know that day never comes.



More importantly, after the successful rollout you can almost count on a diatribe from your friendly neighborhood CIO congratuating the team for speedy delivery followed by a statement that encourages the next release cycle to have an even more tight schedule. After several maintenance cycles, bad code accumulates and everyone has accepted the reality that the code is bad, there is zero opportunity to improve and motivation to do better is destroyed.

With every increasing iteration, developers become even more under the gun and start taking shortcuts. Why spend time understanding convuluted code when it is faster to write duplicate code from scratch. We know that any findings from code reviews won't matter, so just resort to cut-and-paste whenever possible. Now that the PMs have successfully indoctrinated the developers in ways to make quality unimportant, it is now time for the developers to foist this mindset on others downstream in the lifecycle.

Some infrastructure person will sooner or later question the quality of code being released. The developer community will then team up, leverage misdirection techniques and simply blame the infrastructure team for their inability to do proper capacity planning. The infrastructure team over time also gets infected and simply shuts up and adds more servers. Sooner or later your data center has thousands of servers when it only needed several hundred.

You can finish the rest of the story as this is all to familair to anyone who has worked in a large enterprise...

A design review is a typical process in the development of enterprise software where the architect spends time performing knowledge transfer of sage wisdom to the development team. While many believe these ceremonies result in better software, they haven't yet asked themselves if there is a better way...



As an Agilist, I am savage in the pursuit of finding better ways of developing high quality working software. It seems to me that the notion of design reviews fail to acknowledge that there is a significant gap between the architecture diagrams produced by architects and the code written by developers. Even when people were co-located in the same building, their was a strong likelihood of misinterpretation and bad communication. This is only exacerbated when you put Indian IT outsourcing into the mix.

Can we possibly think that a few hours set aside for a review can solve miscommunications either due to the architect not describing their designs clear enough or the developer not being experienced enough to fill in some left-out detail that the architect considers obvious? Independent of this form of idiocy, the action item isn't to call more reviews as the real challenge may be that they are simply called too late in the lifecycle in order to affect change.

It would seem to me that the Agile community actually has a better answer that needs a little extension. Ever heard of Extreme Programming? The notion of building test cases first before a line of functionality is borrowed from the engineering discipline. Before you build a bridge, you should have a clue as to how to test it for load and stress. The same thought process should apply for enterprise software.

Why should architects spend time drawing diagrams that is almost always guaranteed to be misinterpreted when instead they could use design-by-contract and ensure that all subsequent code is testable? What would happen if architects and not developers were responsible for writing/creating test cases? Do you think this could be a solution to removing the predictable deviation from as-designed vs as-built...

In the media, you will frequently hear the rally cry from Republicans on making government smaller and the need for less regulations. While I generally agree with their position, I think it is vital that the American public equally understand when more regulations are also beneficial...



I have spent a majority of my career in the US-based Insurance sector which is probably one of the most regulated businesses on the planet. Unlike other verticals in the financial services sector, the various fifty states do actively participate in creating unique one-off regulations that have no commonality to their peers. This means that an insurance carrier whenever it wants to roll out changes, may need to account for the same theme to be applied to their IT systems with deviations in approach and of course being rolled out at different dates. In other words, insurance carrier IT systems are much more complicated than they need to.

Complexity in this way is sometimes problematic in that it takes a lot of energy to do a little bit of work. Insurance IT employees are sometimes viewed as whiners by their peers in banking and capital markets. The simple fact though is that it is so difficult to roll out software in a compliant fashion is actually a business benefit.

Consider the scenario of if there were only one Federal regulator instead of fifty unique and distinct state-by-state regulators, it would actually make it easier for European insurance carriers to come to the United States, appeal to Obama to simplify laws via hiring a sole lobbyist organization and to then move jobs outside of the United States. With the complexity of state-by-state regulation, this makes it more challenging for a European insurer to make an investment to understand what it would take to enter the US insurance market...

Many enterprise architects have embraced the notion that it is prudent to buy software over building it from scratch, however there are times where EA should hold the opposite opinion...



In my travels, many of the largest P&C insurance carriers are revisiting their decisions in buying policy administration systems and are seriously considering building replacements using modern technologies with people who are in-house. This leads me to conclude that enterprise architecture teams need to wake up to not just the financial considerations behind a decision but to understand IT's role in the business ecosystem and to make decisions within this context.

Many of the P&C carriers feel that vended solutions are in many ways superior to those that could be built in-house. They believe the expertise provided by vendors in system design, implementation and requirements formulation is vastly more efficient and of higher quality than their in-house teams could ever dream of producing. While higher quality is important, they may have concluded that there are considerations that are more important.

In-house solutions allow P&C carriers to attract and retain good IT staff. If everything is outsourced and the in-house role of IT is focused on maintenance then good people may not wish to stay. In other words, good enterprise architects and smart enterprise architecture teams are finally understanding the principles behind Agility. People then process then tools in that order...

Many CIOs and Enterprise Architects are too narrowly focused in their thought processes and may dismiss ideas that on the surface may feel ludicrous but could be gems if they did a little homework...



When I started my career in the 80's as an employee of The Hartford, I remember sitting at my heavy wooden desk in the data center reading about the workplace of the future. It was filled with what we know now as cubicles. Two years ago, there was another workplace of the future exhibit in the home office where space and resources were assigned on an as-needed basis. You had to reserve your space if you were a teleworker and the notion of "hoteling" became at the center of the next workplace of the future.

In each of these "innovations", the basic needs of employees were considered, but only in a lowest common denominator sort of way. Much of the innovation in this regard didn't really benefit the 29,000 plus employees of The Hartford as much as it made it easier for about fifty people who coordinate real estate. Have you ever noticed that many of the so-called innovation processes aren't centered around helping the majority come up with better ideas so much as they are to help a few filter existing ideas? Even if we were to create better filters for ideas while not addressing the how and who filters the ideas, can we end up in a better spot?

Apple was created at a time when all other software companies were focused on engineering-oriented principles yet Steve Jobs had a vision centered on the notion of usability. His ideas were initially ignored by the marketplace and even resulted in many failures, yet his persistence never wavered.

Every time I look at the innovation processes of corporations I visit, I always ask myself how back testable are their filters such that they wouldn't get rid of ideas that were originally deemed as ludicrous but now have been proven wildly successful. One example that comes to my is FedEx. FedEx was the result of a student writing their college thesis where the professor indicated that the idea couldn't have possibly worked. Now we know better.

For enterprises that want to be more innovative, wouldn't it be a better practice if they honestly asked themselves the following questions:

• Are executives the right people to filter ideas?


• Should we separate out the person who controls the budget for exploring ideas from the person who approves the ideas?


• Does our process allow us to revisit ideas that may have potential in the future or is it a we have voted, once and done?


• If I do not understand an idea, does that make it bad where the person submitting the idea needs to refine it or does it mean that I should make myself smarter in order to understand it?


• If I declare too many ideas as being ludicrous early in their life-cycles, am I helping or hurting long term innovation?


• If I truly want my enterprise to be king of innovation, how do I eliminate the the fact that fear of failure is often stronger than the desire to succeed, not only within my people but most importantly within myself?