This morning I posted the following comment on the CAEAP website
“I see there are work tracks that focus on ‘Enterprise Architecture Professional Learning Framework, value to the practitioner’. I think it would be interesting to consider here a move away from a focus on frameworks and a move toward apprenticeship. My personal experience is that frameworks don't help individuals become architects, it just provides a tools for organization of artifacts. Yet, I believe the industry believes that these frameworks (DoDAF, TOGAF, FEAF, PEAF, Zachman) help non-architects do an architect's job.”
In my experience, all these frameworks provide a way to think about and organize the artifacts that are part of enterprise architecture, but a framework cannot make you an architect. Additionally, these frameworks provide a means of breaking down the work effort to collect these artifacts, which can be done by non-architects. But, in the end, all these artifacts need to be analyzed against a set of business goals, which then leads to the production of a design that aligns technological direction with the mission of the business.
Which brings up an interesting question, “who is using the framework?” In some cases, the framework has become a bureaucratic milestone on the way to approval. It doesn’t tell anyone who isn’t an EA anything more than what’s been collected about the current environment. There certainly is no way to ensure that the entire current environment is even fully represented by way of the artifacts that are represented. It’s merely a checkmark on some bean counter’s checklist before releasing funds.
If an EA is using these tools, more often than not they are stymied by the lack of support for emerging architectural approaches. As an exercise, try to find a standard way to capture an SOA design using one of the various EA framework approaches. Sure, people are hard at work trying to retrofit these standards to support emerging architectural methodologies, but these approaches take time and are often years behind the industry.
Most importantly is that enterprise architecture frameworks are designed to be tools. A chisel in the hand of a sculptor will yield a work of art, but in the hands of an amateur yields a pile of rubble. The same is true for any of these frameworks. We need to focus on the creation of architects. I believe the IT industry has been remiss in this effort. Sure, they pay for a few conferences, but architecture is something that is culled over time and based on seeing mass of systems being designed and built. I believe instead of certifications, we should focus on apprenticeships. The resume of an architect should read,
“Studied under XYZ from 2004-2006. XYZ has been responsible for … at … While studying under XYZ I was subject to delivery of the following types of systems.”
While I’m on the subject, I believe the same is true for cybersecurity experts.
Apprenticeship is a lost art in the world, which is a shame. Our desperate need for resources today has limited our long term vision of what the IT industry needs to thrive 20, 40 or 100 years from now. Business believes systems can be designed like a McDonald’s hamburger and that developers and architects are nothing more than the lettuce station and the fry station.
Why do we consistently see headlines, such as “SOA Is Dead”, “EAI Is Dead”? It’s simple, because all these things are really complex and you can’t approach them with an assembly line mentality. Forget Henry Ford already, look at Detroit, learn a lesson people! Focus on developing quality, which means selecting those individuals capable of being architects and supporting them through apprenticeship programs. Moreover, support the creation and execution of apprenticeship programs in your organization.
[ 11 comments ] ( 8 views ) | [ 0 trackbacks ] | permalink
I just want to give a shout-out to all those IT people working their butts off everyday and taking crap for it.
Over the years I've been witness to IT people being abused by the business for not delivering, when in fact, it's the business putting IT in a "no win" position.
One one hand, the business expects IT to make sure that computing resources are used effectively and that costs are kept in check. This includes application procurement, development and computing infrastructure. However, the business also expects IT to not stand in their way when they want to get something done.
Question for the business, "how do you expect IT to keep costs in check and optimize resources when you demand the ability to do whatever you want whenever you want using whatever tools and people you want?"
Look, over the years, I've been a big supporter of IT needing to operating in "business time" and I still believe it is an important goal. That said, one of the major hindrances to this is the lack of adherence to standards where they exist and the end-runs around IT when the business doesn't like the choices IT makes.
IT, this doesn't mean you're off the hook to accommodate the business. Remember, we're here to support he business, not the other way around. You need to pick standards that make sense to the majority of users. Make sure you have done effective enterprise architecture design before making decisions on products and standards; especially products. Don't be swayed by vendors promises. Make sure the business agrees to the value proposition.
[ 1 comment ] ( 10 views ) | [ 0 trackbacks ] | permalink
Wow, to read the positive reviews of SOA and what it’s doing for the IT industry, one would be likely to believe that there’s serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using today’s technology mix, is complex, clumsy and fraught with sandtraps.
I was discussing this topic with a friend the other day who is a big advocate of “just focus on the work and stop worrying about the ideology”. I know this person knows how to develop maintainable and sustainable solutions, so when he says “just do it,” I know that implies just do it using common, agreed upon best practices for developing agile software solutions. So, we kept beating about this concept of sustainability and we both finally agreed upon that the key is focusing on understanding the business. This means sustainability comes from analyzing from the top down, not the bottom up as bottom up results in tactical solutions that do not conform to the needs of the business over time.
I know this last statement is controversial. After all, it’s difficult to accept that if you develop using good component-oriented approaches that you can’t retrofit today’s bottom up for tomorrow’s bottom up. But, the fact is that bottom up expresses the “how” not the “why” and the “how” is limited by the subjective reality of the person(s) providing the information. However, truly understanding the business allows the architect to design to an objective goal that can be presented in whatever subjective ways is needed today.
But, let’s revisit my opening premise that implementing SOA designs today is complex, clumsy and fraught with sandtraps. I believe the complexity stems from the fact that SOA works best and is most easily aligned with loose-coupling when services are stateless. This means that the service retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer.
Moreover, a service should operate in a deterministic manner and the consumer should make no assumptions that the service will operate differently based on same context. Most importantly, if any part of the implementation is implicitly linked to any other service’s or application’s implementation, then it may not maintain the ability to switch contexts as needed based on the consumer.
In many cases, statelessness is in direct opposition to the goals of business applications, which are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular application’s requirements, limits the service’s ability to operate in multiple application contexts.
For example, if a service uses a single database table that has relationships with other tables (e.g. foreign keys), and the service has no use for the data in those related tables, but yet the database is going to enforce data integrity when this one table is operated upon, thus forcing the service to be cognizant of those relationships, then loose coupling is broken simply based on the virtue that a consumer is forced to be aware of information that is outside of the scope of the service.
Additionally, there has been a strong emphasis on reuse with regard to SOA, to the point where reuse has become the single, determining factor for defining a service. However, reuse is a completely orthogonal issue to SOA. Reuse is driven by two factors, levels of specialization and interface. Low levels of specialization will drive reuse, however, high-levels of specialization do not necessarily invalidate a service design—it just makes it less reusable. An interface is merely the entry point for communication. Thus, we can create reusable components that cannot operate without the consumer’s explicit knowledge of other areas of the system, for example, a program ID, and because of these constraints disqualify it from being loosely-coupled, and hence, not a service in the sense of SOA.
I believe if you review many of the systems that today call themselves SOA you will most likely find service-enabled applications comprised of reusable software components and Web Service interfaces. Because many of today’s SOA platforms do not yet provide the necessary means to really enable true loose-coupling without sacrificing things like data integrity across services, implementing SOA designs today often requires concessions that make the resulting service less sustainable.
[ 7 comments ] ( 25 views ) | [ 0 trackbacks ] | permalink
Blogging about technology is enjoyable for me. It allows me to explore my interest in the topic, but sometimes, there are issues that just need to be reflected on that have nothing to do with technology.
America is a big and complex country, but culture is something that is usually consistent and prevalent in a geo-political area. Saturday night I was presented with these two conflicting representations of American culture.
"Later on when I got home, I flipped the TV on
I saw a little town that some big twister tore apart
And people came from miles around just to help their neighbors out
And I was thinkin' to myself I'm so glad that I live in America" -- Rodney Atkins from his song It's America
"Greed isn't good! In fact, it's the common thread that runs through all the problems this country faces from financial meltdown to health care to climate change, Americans will do anything to each another for money .... we do it all to each other, the killing and the keeping people sick and poor and in jail and destroying their habitat because a generation ago Ronald Reagan and Gordon Gekko told us 'Greed is Good'. Humans have always been greedy, but they never convinced themselves it was good" -- Bill Maher - New Rules (05-29-09)
I was left with the thought, "will the real America please stand up!"
[ 1 comment ] ( 3 views ) | [ 0 trackbacks ] | permalink
I saw an announcement this morning by WSO2 that they are offering free SOA Training this summer; this triggered my “uh-oh” senses. I'm sure that WSO2 means well, but I've noticed a trend in my conversations with individuals who have a predominantly been trained by “SOA Vendors” to focus too heavily on the implementation design factors and focus too little, or not at all, on a top-down approach. To me, this makes perfect sense, because, and I know this is a contentious statement, architecture cannot be taught to the masses.
The results of bottom-up engagements, which are labeled as SOA, are faster delivery, increased reuse and lower development costs—all good things. However, these solutions are constrained by their limited aperture, which results in too narrow of a focus and misses capturing the necessary domain knowledge in to the architectural model—the key promise of SOA—that will provide the aforementioned benefits horizontally, not just vertically in a single business domain.
Hence, the business leaders are disillusioned. It's not that they don't see the benefits to software development, but because they still don't have a solution that enables them to execute in “business time”. Without leading with a top-down design, the necessary subject matter expertise, and subsequent service model, to enable rapid delivery of a large, complex, enterprise-wide business processes is missing. The outcome of this latter point is that as the business tries to reposition with market changes, in the eyes of the business, IT still cannot keep up and all the talk of the benefits of SOA is diminished. Thus, SOA is yet another instance of “all talk, no action.”
But, let's not lay all the blame at the feet of vendors offering training on a skill that is not designed to be learned in a classroom over five days, but is a craft that needs to be honed over years working with talented craftsmen. Part of the blame need to be placed back on the business for believing they can get something for nothing. Much of the business community does not respect the value of architecture, is too focused on tactical wins and allows themselves to believe that they can create an army of low cost programmers, send them to a vendor-led SOA class and have them churn out projects that can meet anything more than a small community of interest's needs.
Of note, I lay a lot of this blame on middle management that has never learned to have critical conversations with their executives. I believe most senior executives are strategic thinkers, which is how they achieved their current position. However, middle managers are not trained to manage the expectations of their executives, and thus, believe if they don't show constant momentum, they will be deemed incapable of delivery and relieved of their duties.
Well, you cannot show current momentum if you've bought into the promise of enterprise and service oriented architectures—you've bought into the promise that strategic modeling of the organization will ensure that the real business needs are met in a way that drives agility and allows the business to keep up with market demands. Middle managers that learn how to manage the expectations of senior management through this process will win in a way that will surely position them for growth.
So, while its been a long and winding path to the answer—subsequently, a path that truly shows how everything is connected to everything—the answer is that vendor-led SOA training is not a good idea. Vendors have a mission, which is to sell software. To them SOA is something you build, not something you design. Hence, the focus from the gitgo is a failure and will lead to continuous disillusionment.
If the goal for the organization is to develop software faster, cheaper and with more quality using CMMI-like processes, then many of these vendors will help you achieve your mission and be successful. However, do not believe for a second that what your programmers and engineers learn in these classes will help at all achieve the mission of service oriented architecture, because, architecture cannot be learned in a classroom in five days; only architectural principles can, which are like sharp knives in the hands of babies if not properly directed.
[ 2 comments ] ( 10 views ) | [ 0 trackbacks ] | permalink
SOA is Dead, No Wait, It’s Alive, Wait, No, It’s, It’s…Perhaps It’s Who’s Adopted SOA, Not What Has Been Adopted
I'm currently reading “Influencers”, in which the authors make a great point that with innovation, the messenger is as important as the message. There’s a story of a researcher who attempts to get farmers to use a more disease resistant strain of corn, but the farmers don’t view this person as experienced and don’t want to risk their crop. So, the researcher sets out to find that one person who will try the new strain of corn, thereby, setting an example for all the other farmers. So, the researcher finds this farmer that dresses in Bermuda shorts and drives a Cadillac, who is open to innovative farming techniques and who successfully uses the new strain of corn to grow a bumper crop.At this point, most of us “engineer” types are thinking, “great, now all the other farmers have an example of it working and will feel more comfortable using the new corn.” I know I will raise my hand with regard to being in this camp, but I got schooled in a big way. I know that when I was out there acting in a business development / sales role for software companies, this was a critical factor for success. Moreover, in certain industries, such as finance, this approach works great.
However, we in IT often focus so heavily on the successful early adopters, that we forget about the majority of middle-roaders and laggards. Why are they middle-roaders and laggards? Well, as it turns out, when it comes to innovation, adoption is sometimes more limited by who adopts first than the fact that it was adopted and worked successfully. Middle-roaders and laggards weigh certain, maybe less visionary and less well-advised, opinions more heavily than the data they can view with their own eyes.
I’ve noticed this phenomenon, but didn’t have a full understanding of the processes that were occurring. Especially with regard to SOA, I remember in the early days being concerned that ITs early adoption of the concept might chase away the business before they had an opportunity to digest the value to them. Sure enough, I believe this is exactly what has been occurring. A concept that was supposed to bring IT/Business together has once again ended up having too heavy focus on IT and the business is now rejecting.
This brings us back to our Bermuda-shorts-wearing-Cadillac-driving farmer. As it turns out the other farmers did not respect this farmer because he was different and because he didn’t think and do things the same way they would. Hence, they rejected the cold, hard data that his crop surpassed them and, as some might say, “bit their nose to spite their face.”
When it comes to SOA, isn’t the Business a bit like the other farmers? If IT wants to succeed at leveraging the power of innovation, whether its Cloud Computing, SOA, Enterprise Architecture, etc. they’re going to have to stop “geeking out” and taking dominance over these creations and allow the influencer groups that the Business listens to take the lead and promote the value of these new innovations.
[ 2 comments ] ( 15 views ) | [ 0 trackbacks ] | permalink
A colleague recently sent me some IBM propaganda on SOA, BPM and EA. Discussing my opinion of the white paper with him sparked an idea for a blog entry about the my opinion on the relationship between these three methodologies.
Okay, let’s dive into the meat of the issue. What, if any, is the relationship between SOA, BPM & EA? First, some quick definitions:
BPM is a practice that focuses on identifying if a business process is operating within normal operating ranges. How can you tell that? First, you identify some key performance indicators (KPI) that you will use to measure your business process (this implies you actually understand your business), next you have to baseline your current business process; lastly, you modify one variable at a time to see the impact it has on the process. Since this last step can have financial impact for your business, you may want to consider using simulation to assist in this process.
SOA is a practice that focuses on modeling the entities, and relationships between entities, that comprise the business as a set of services. This can be done on a small or large scale. Typically, the relationships in this model represent consumer/provider relationships. Doing SOA correctly implies you are taking a top-down approach. I’ve seen/read views that discuss the bottom-up approach to SOA and I don’t believe the results of that represent SOA. Perhaps it’s a component model, but not a services model. The value of SOA is that you are aligning IT with the business using this architecture methodology.
Finally EA is the ‘Big Kahuna” of architecture practices. It attempts to get the architect(s) to take a holistic approach to thinking about the organization approaches delivery and support of solutions on an enterprise scale. The goal of cataloging and modeling at this scale is that you can see “the forest from the trees”. It’s very easy to think about solutions in your organization based purely upon need, but you will end up with a set of disparate and disconnected silos. Cataloging that need in an EA enables the organization to recognize consistent patterns and consolidate around them. Thus, operational costs are reduced, redundancy is avoided and time is spent solving the unique aspects of new problems rather than continually reinventing the same solutions over and over again.
Now I will provide my opinion on the relationships between these methodologies:
SOA & BPM: SOA & BPM are methodologies, not tools or technologies. It’s irrelevant if SOA suites can do BPMS or BPMS suites support SOA. There is no inherent relationship between these methodologies just because vendors discovered that that they can use Web Services as a means of execute a task within a business process. Web Services is not SOA, it is merely a standardized approach to accessing functionality on remote systems.
However, a well-designed SOA can simplify BPM by enabling rapid business process modeling that only needs to go as deep as identifying the right service rather than having to identify the entire sub-task. SOA can also simplify BPM by denoting in the service the types of KPIs that the service maintains for itself. This requires full understanding that a service is a measurable unit and that metrics are a key component to development of the service contract. If you can’t measure it, it’s not a service!
EA, SOA & BPM: SOA and BPM are views within the enterprise architecture. They don’t replace the need for EA and they cover only a small subject of EA’s requirements.
[ 3 comments ] ( 58 views ) | [ 0 trackbacks ] | permalink
Yesterday, I read Fowler’s “Who Needs an Architect” , which is an odd piece that never really answer the question to my liking, but it did get me thinking.
For me, being an IT architect is a full time job that has many facets. One facet is designing systems and applications; this facet is primarily controlled by experience. This facet incorporates requirements gathering, joint application design (JAD) and planning. The more hands-on experience that an architect has, the greater the likelihood that the design of the system will meet the requirements while requiring few modifications to support growth and longevity. This does not mean that we cannot build extensible systems in a generic manner, but ultimately, being able to balance generality with domain-specific knowledge, which requires seeing ten steps ahead, will deliver a system that is most capable for the domain that it is being deployed. This is where I spend the bulk of my time, 65%-80%.
Another facet of being an architect is staying abreast of changes in the field. One day you’re arguing the best CORBA persistence mechanism with Chris Stone of the OMG and before you know it you’re faced with the need to understand the implications of using Struts, Spring & Hibernate. In this field, things change at an incredible pace. I try to spend 15%-20% of my time keeping abreast of emerging technologies and it’s difficult at that pace. Why is this important for an architect? Because there’s a lot of ideology around these tools and they have the capability to speed development, but they also have the equal capability to cripple performance and testing. It’s important for the architect to understand how technology choices will impact delivery, deployment and maintenance.
The final facet of being an architect is relating design decisions to a diverse population of stakeholders, which includes business representatives, peer architects, management, quality control and users. It’s known that people hear subjectively based on their own experiences, so when you’re presenting a vision of the future state of an existing system, or the more difficult, the design of a new system, where there is no experience to pull upon, one wrong word and the sand trap opens swallowing you up. You’ll spend so long explaining your way out of the trap that the entire vision and all the value it brings will be lost. I spend 5%-8% of my time reading articles and books that help with leadership and influence issues to assist with this responsibility. For me, I also do a lot of education as a way of sharing, which includes blogging, writing books and speaking, so I include that in this facet as well, but I don’t believe it’s necessary for all architects to be educators as well.
What’s most important is that I have found that these three facets feed each other. Many architects I know do one, maybe two of these, but I have found that the trinity is what creates a well-rounded architect capable of bringing value to IT processes.
So, to answer Mr. Fowler, architects are critical members of the IT team that lead the efforts to deliver systems and applications for the business that meet their needs in the shortest time frame without sacrificing growth and performance. The business needs them!
[ add comment ] | [ 0 trackbacks ] | permalink
