Mike Blechar
VP Distinguished Analyst
17 years at Gartner
43 years IT industry
Michael Blechar is vice president and distinguished analyst in the Information Management Research area of Gartner's Research and Advisory Services. Mr. Blechar specializes in the area of metadata management/repositories, information and data services…Read Full Bio
by Michael Blechar | April 29, 2011 | 1 Comment
A frequent question I get from clients is how to justify a metadata repository based on return on investment (ROI). I generally discuss issues with the client such as which information assets need improved metadata management to provide some quantifiable added value to some specific business opportunities and threats. This added-value (the positive ROI) must then be compared to the additional costs of software, personnel, training, consulting and process changes. And, not just the one-time cost and savings but the ongoing license and metadata management costs as overhead versus potential ongoing savings.
In other words, this tends to be a very personalized discussion (between me as a Gartner analyst and a Gartner client) which is unique to each organization considering implementing a metadata repository.
But I find that there is generally a basic flaw in how organizations define the “gap” between the current environment and the one in which the metadata repository would be implemented; there seems to be an assumption that the organization would be moving from a status of “no metadata management” to one in which metadata is fully managed (within the scope chosen). This is almost never the case.
Whether metadata exists in people’s heads, or in Word documents, Excel spreadsheets, PowerPoint or disparate tools, it generally exists in one form or another. Therefore, when calculating the ROI for a metadata repository you are calculating the value of a “better solution”. This can be extremely tricky and subjective.
For example, if a data element needed to be changed in a data warehousing table, a metadata repository could tell you all the databases, ETL (extract, transform and load) scripts and business intelligence queries which would be impacted, saving time and improving quality (both of which can be measured in terms of ROI). But, how much is actually being saved?
Chances are that I could find this information out by looking in three places – a database design tool, an ETL tool and a BI tool in a less efficient manner. But, it would be lower software costs and have no ongoing overhead associated with keeping a repository synchronized or federated with those tools when changes happen. It is THIS gap which needs to measure in terms of ROI, including whether the improvement really makes a big different to the bottom line or not.
Now I am not saying that metadata repositories are not a “better solution”. But, I am saying that building a business case that it is a better investment than spending the money in other ways is not as clear as having “no solution” versus a “needed missing solution”. Generally if the need was great enough you’d already have a metadata management strategy and repository in place to address the problem. And frequently metadata management questions involve other people (maintenance programmers, end users, etc) – meaning that you also have to factor into the ROI “gap” the time they need to spend on resolving metadata management questions versus other use of their time to generate ROI for something else.
Net: The discussion around the ROI of metadata repositories is a complex one I have with clients. It needs to be scoped in terms of the specific business opportunities and threats being addressed and how well they are being met by the “current metadata management capabilities” weighed against the one-time and ongoing costs of “upgrading” to a metadata repository. Each organization will find it has a unique range of best possible options for addressing metadata management based on the alternatives of build, buy or “live with what you have” (sometimes with procedural or naming changes as an incremental improvement).
It’s questions like this keep me challenged and employed (and knowing that I’m helping our clients be successful)! 
Category: Uncategorized Tags:
by Michael Blechar | March 31, 2011 | 1 Comment
When I started programming in the 1960s, application development was predominantly an engineering discipline done by a handful of math/science-oriented “professionals”. Most of the early applications we built were foundational to the business, and as such required reliability as a major component. Estimation of effort, time and cost was more an art than a science for most projects and the business user was willing to live with those constraints as long as the resulting solution reasonably met his or her most important needs. Interestingly, in most organizations of which I was part, requirements were generally gathered in an informal/ad hoc manner and loosely followed a design-code-test-implement set of concepts rather than some formal AD methodology.
Jump forward about 15 years and we were still pretty much in the same boat in terms of engineering new (or enhancing existing) foundational applications. But, due to all the project failures we began to see most organizations implement more guidelines for AD processes and methods. Since reliability was still the predominant issue, “waterfall AD methodologies” like Yourdon, Information Engineering, etc, were more commonly used to ensure a more consistent result. But, of course, the additional architectural and analysis steps also tended to made these somewhat slower to solution delivery than previous “design and code” approaches. Some of this was overcome through the use of complementary enterprise-4GLs for simpler or more ad hoc development needs.
Fast forward to today’s environment with more widely IT-literate application developers and users. Time is money and money is limited. Business and application agility generally trumps reliability. And, making things worse, all those foundational applications are now interfaced/integrated in dozens of ways making change management problematic. We have moved from engineering to managing a “solution architecture ecosystem” where application development is having to deal with the biological impact of change on those foundation applications, along with those we have bought, are part of the supply chain, or increasingly exist “in the cloud”.
We have new “agile AD methods” which are being used to extend those legacy and purchased applications and data through new browser/portal technologies using concepts like mashups and compositions. But not everyone is being so successful with agile methods on all their projects. We are seeing “basic agile methods” used enterprise-wide on “do it quick” projects – many of which might be highly innovative and provide important business value. However, we are also seeing many failures on the agile projects where iterations of delivery (i.e. improving functionality and reliability over time) are insufficient to meet “enterprise-class” needs for quality, coordination and integration. in some cases organizations have erroneously backed off the use of agile methods completely, even where they should be the most appropriate choice.
What’s needed is a segmentation of project methods into at least 3 categories; 1) the more self-contained simpler applications using basic agile AD methods, 2) waterfall AD methods for highly inter-dependent and complex applications, and 3) an emerging hybrid of the two which we at Gartner refer to as “enterprise-class agile AD” for projects whose needs are a greater balance of “do it quick and get it right”.
Best Practice: Make multiple “flavors” of AD methodologies available to your projects and select the one which best matches your needs based on a variety of factors including the requirement for speed versus reliability. Agile methods ought to be part of that portfolio of methodological options.
Note: Gartner customers can read more about this topic and the factors to consider in “Enterprise-Class Agile Development Defined”, “Enterprise-Class Agile Development as Part of the Enterprise Solution Architecture” and “Selecting the Best Project Approach to Application Development and Composition”.
Category: Uncategorized Tags:
by Michael Blechar | February 27, 2011 | Submit a Comment
Did I get your attention there given that we generally hear about the need for more consistency and consolidation of applications and data. Let me first clearly state that I wholeheartedly support consolidation efforts where they make sense. But, there are enough cases where consolidation may not be the right answer that I thought it was time to blog a short piece on that topic.
First, there is the issue of politics and culture. The reason we have inconsistent and siloed applications and data is that the business architecture rules prevent consolidation from occurring. This might be due to the fact that each business unit is being run as its own profit center in a de-centralized manner and each is dealing with agility issues or conflicting business rules by having their own solutions. Or, there may simply be an unwillingness to coordinate and collaborate across the business units which executive management does not care to address that makes consolidation not viable in the organization. That is not the focus of this blog.
Let’s take the case where the organization has the desire and ability to consolidate its business processes (and the related governance issues which in turn impact the sharing of applications and data which implement those rules). This willingness to share is normally good news for the IT department as it allows them to decrease the number of redundant applications, databases transactions and services which, in turn frees up resources to work on other IT priorities in support of the business units. But, I would suggest that there are at least two key factors which really need to be considered when deciding on what and when to consolidate; 1)Complexity and 2)Reusability.
Complexity: Removing application and data redundancies generally also means removing the number of interfaces in which the applications and data participates – i.e. simplifying the application and data architecture. If the consolidation results in a single agreed-upon set of applications and data with consistent and shared business rules, the level of application and data management complexity decreases along with the lesser numbers of applications and databases needing to be supported.
However, if the consolidation means that the applications and databases are merely a means of taking all the old and inconsistent rules from all the legacy solutions and propagating them into a smaller number of new consolidated solutions, what you end up with is substantially more complex applications and databases. Think of this creating “the next generation of spaghetti code” (interwoven and inconsistent strands of code) where the slightest change for one set of rules can have negative impact on all the other versions of the rules in the same application or database. Testing time and costs go up, quality goes down as failure rates go up, business agility decreases, etc.
So, to summarize, application and data consolidation works best when you ALSO consolidate the business processes to have a higher level of business rule sharing and related sharing of governance across the business units. Otherwise, while consolidation might reduce some number of application and data interfaces it may actually result in significantly more complex (and costly) applications and data. You need to do the return on investment math to decide whether in a given instance of application or data consolidation the new solution results increased cost of application or data complexity – and if so – is offset by the savings in relation to other factors (such as reduced number of resources needed for a lesser number of applications and databases, etc). This is a business decision, not a technology one.
Reusability: Obviously, the more convoluted/complex the newly consolidated applications and data are the more difficult they will be to share – and perhaps even more importantly, be able to support that sharing as rules change within the applications and data in support of one user which are not needed by others. So, when the business architecture/governance rules are not truly shared, the resultant complexity makes further sharing more difficult, not less.
But, in fact, the converse is also true….the more shared the business architecture rules are across business processes, tasks and steps, the more reusable the implementation of those rules will be in the form of the applications and data which support them. What we are talking about here is moving to service-oriented paradigms in terms of designing the business processes, which in turn permit the use of service-oriented architectures (SOAs) by IT, including physical design and implementation of more broadly reusable application and data services.
And so, my second major point here involves “when and how” to do application and consolidation. To some degree it’s a question of the chicken and the egg; do I first do a master data management (MDM) project to provide real-time federation/consolidation of the current (inconsistent and redundant) data into a single/shared best source of information and/or provide a new layer of service interfaces to the legacy environment with all its flaws, or do I instead consolidate all the applications and databases to share a new common set of service-oriented business process rules in a SOA – or some hybrid solution of the two approaches for different business units, applications or databases?
There is no right or wrong answer “in general”. This requires having a solution architecture strategy which allows the organization to see what is due to change and when, looking at the status of the existing solution portfolio and its costs and ability to meet the users needs based on the solution architecture strategy, and the making some good business decisions on what role SOA and/or application and data consolidation will play in the transition strategy.
Net: Philosophically, application and data consolidation are good objectives to have. However, without the business managers agreeing to more shared business rules and services there are opportunities and risk related to wholesale consolidation; these include potentially increased application and data complexity and risk, decreased responsiveness to change/agility as well as decreased reusability. Conversely, by first getting business managers to share business rules and services, it is possible to address consolidation through a software and data services layer with selective consolidation of legacy applications, data and workflows.
Recommendation – Be informed and selective when it comes to application and data consolidation in terms of the value it brings to the business, as opposed to treating wholesale application and data consolidation as “a goal unto itself”. Consolidation can have the greatest payback when you “break down the application and data silos” which exist in your legacy environment and replace them with newly designed and shared application and data services which support more widely shared business processes and rules.
Category: Uncategorized Tags:
by Michael Blechar | January 31, 2011 | Submit a Comment
Such was the question posed to me recently, and I chose information management (IM). So, after 17+ years at Gartner I am moving from the Applications team of analysts to the one focused on IM. Actually, this is not a new question for me……
I entered the computer field in 1968 as a programmer, and later worked my way up to the programmer/analyst and systems/business analyst roles. Around 1975 I was invited to interview for a job with American Company as a “data analyst”, Believe it or not, I was not that familiar with the concept of databases or data design (which were starting to emerge back then). And so then, as now, once I understood how important IM was, I was excited by the prospect of focusing on IM and decided to leave the field of application development (AD) for a while.
I actually spent about 10 years working on all aspects of IM, including a focus on metadata management and repositories. In the mid-80s, based on my knowledge of AD, IM and metadata, I was approached by a vendor (CGI Systems) to be the US product manager for a model-driven code generator (CASE tool), Pacbase. To be honest, those 5 years were as much about IM as AD when doing CASE projects using concepts like parallel decomposition of data and process diagrams.
Later, I would parlay all those things together into a management position to head up an organization which focused on IM and development methods and tools at Blue Cross/Clue Shield of Florida.
My true love, however, has always been in research. And so, when the opportunity arose to come to Gartner in December of 1993 I jumped on it. Back then, I was in the AD research team and wrote on CASE tools, business process analysis/modeling tools, data modeling/database design tools, and metadata repositories. In recent years I have been in the Application Architecture team with a focus on the collaboration of application architects with others doing enterprise, technology and business architecture and their relationship to AD analyst roles and tools.
So why IM again now? Two reasons, related to what I see as the re-emergence of the importance of IM:
1) As we increasingly add new types of mobile devices, social networks, Cloud computing and other types of technologies and applications on top of existing data structures, the data architecture becomes even more important and requires change (especially in terms of the layer of data services and data transformations) in order to support new agile business process requirements.
2) Metadata management – which permits the understanding of how this all fits together – becomes a critical set of technologies and disciplines, not only to the IM team, but to all aspects of the enterprise.
And so, in my new position, I look to have a greater focus on the issues of metadata management and information services and collaboration with the business and developers.
Net: Organizations need to have personnel who are good at both Applications and Information (and in collaboration). But for the next few years I look forward to once again focusing on IM as a priority for my research!
Category: Uncategorized Tags:
by Michael Blechar | December 8, 2010 | 2 Comments
As I prepare to shut down operations for the year, I reflect on some of the most frequently asked questions I get when I visit Gartner clients – What is an application architect?, What does the application architect do?, and How does the role of the application architect relate to others, such as application developers, enterprise architects and solution architects? This led me to co-author with Bruce Robertson the following three research notes (which were just published today) to address these questions:
Application Architecture Overview, Part 1: General Context and Scope*
Application Architecture Overview, Part 2: Enterprise-Level Scope and Roles*
Application Architecture Overview, Part 3: Project-Level Scope and Roles*
Part of the confusion is that MANY roles contribute to the application architecture, not just the work of the “application architect”. For example, the role of the enterprise solution architect (ESA) addresses the conceptual/planning level of the application architecture in collaboration with other architects focused on the needs of the technology, business and information architectures. The ESA ensures that the application portfolio evolves at an appropriate rate and does not become unviable as the other related architectures change. The ESA also provides the reusable standards, guidelines, patterns and frameworks to application development projects, including those related to application architecture.
At the project-level, solution architects make sure that all aspects of the application solution architecture are optimized (as much as possible given other constraints of time and budget) by working with subject matter experts (SMEs) in the areas of technology, information and application architectures and disciplines. The application architect is the SME focused on designing application interfaces and software services to maximize reuse based on the business processes and governance rules for sharing.
As organizations move to service-oriented architectures (SOAs) where applications are composed via the assembly of reusable application interfaces and services, the role of the application architect becomes crucial to help reduce development time and costs while also enabling application and business agility. So, to net this out, implementing the role of the application architect is a critical success factor for SOA.
Happy Holidays!
*Available to Gartner clients or for a fee
Category: Uncategorized Tags:
by Michael Blechar | November 27, 2010 | 2 Comments
Now that I am back from the Gartner ADI Summit in Los Angeles, I thought it was time to post some musings on the questions which came up during my presentation sessions and face-to-face meetings with clients. One common thread to these questions I received involves the #1 attendee issue identified by our Gartner pre-conference surveys – collaboration between IT and and business. Not surprisingly, my most highly-rated session was “IT & Business Collaboration: SOA, BPM and MDM”, which looked at the inter-dependencies and leverage points between service-oriented architecture, business process management and master data management.
Interestingly (at least to me) I discovered that since attendees were filling a large variety of roles for their organizations, though most had some degree of concern about IT and business collaboration their viewpoints on what the problems were and – perhaps more importantly – why these problems mattered varied widely. For example, many enterprise architects thought the lack of collaboration resulted in an ability for them to design a good technology architecture which met both the current and future needs. Data architects and analysts were concerned about data quality and inconsistency problems with which they dealt on a daily basis yet the business seemed to be ignoring. Developers seemed mostly concerned about how to get the business to specify correct requirements so that they build applications more quickly, while application architects were mostly concerned about how to fulfill their role in removing redundancies caused by the business units funding the building and maintenance of siloed applications (instead of focusing in shared and reusable software services).
Or to say it a different way – each of the attendees wanted to improve collaboration to solve THEIR problems as opposed to those which the business perceived as the most important to them!
I told a joke (which I will shorten here) to illustrate this point. A couple of hikers are near a farm and come across a large, deep hole. In order to find out how deep it was they threw a heavy railroad tie near the hole into it in order to hear the depth of the thud at the bottom. All of a sudden, a goat came running at breakneck speed out of the woods and dove into the hole headfirst (with an accompanying “splat” sound when it hit the bottom). The local farmer showed up and asked the hikers if they’ve seen his goat, which was on a long chain attached to a railroad tie. Ta-dum….
My point of this joke to the audience was that the business believes its only concern and responsibility needs to be the care and feeding of the goat. The business perceives IT (SOA, MDM, AD, etc) to be that big deep hole – and aside from cost issues and getting solutions they need, the business considers the hole to be the domain and responsibility of IT. It is not until the business understands that there are inter-dependencies between the hole and the goat that they care. So, the trick becomes in turning the answer to the “why is IT and business collaboration important” question from one which has relevance to me into one which has significance to the business.
I generally talk about 2 key enablers of IT and business collaboration. The first is at the conceptual/planning level of detail where there needs to be a representative from the business who brings the plans and needs of the business units to the table to be considered in the context of the other viewpoints of technology, data and application. Once the business sees how this collaboration can expedite the delivery of solutions, improve agility of change, help decrease costs or allow them to be more efficient or competitive, they finally begin to see the relationship between the goat and the hole and the need for collaboration.
The second enabler getting the business to work on (re)designing their business processes and workflows using service-oriented methods as part of BPM initiatives. Note: Much as the business perceives hole as an IT responsibility, too many IT organizations see BPM (in support of the goat) as a business responsibility. IT needs to enable BPM initiatives since these result in greater collaboration across business units and, in turn, results in projects which specify requirements to break down the silos which exist in IT systems between applications and their data. Or to say it more directly – BPM is the most important enabler of change for driving greater collaboration of the business units across application systems (and therefore with IT) because the need for sharing creates a greater need for collaboration.
At a minimum, IT personnel need to make sure they ASK the business what aspects of collaboration they feel are negatively impacting them – either from a business cost or efficiency perspective or in terms of holding the business back from being more competitive or generating more revenues. And then, whenever possible, IT needs to assign resources based on priorities agreed upon with the business to address those issues in order to build trust greater trust and to enable greater future collaboration.
Category: Uncategorized Tags:
by Michael Blechar | October 29, 2010 | Submit a Comment
As someone who is in the “Application Architecture” group at Gartner, and with over 40 years of experience in various forms of application development, you would presume that I could easily define what an “application” is. But, increasingly, with the emergence of more granular software services being reused across shared processes and workflows the question of what an application is becomes more what business-related services are offered.
My colleague Jim Duggan just published a new research note on this issue from an application portfolio management perspective (“Defining ‘Application’ for APM*”). His conclusion is that as an application portfolio management program matures, more-complex definitions will be needed to map the multiple stakeholder views together for coherent analysis. A single application definition cannot be achieved, and recommends starting with IT-based definitions while moving towards more business-process-driven ones.
This also has ramifications in terms of the “application architecture” as a subset of the broader enterprise solution architecture as “application design” requires understanding the ramifications of performance of software services in terms of the technology solution architecture and agility and reuse in terms of the business process solution architecture. And, as application/solution architects design XML “data-in-flight” files to pass data between software services and make decisions to embed data rules in software services rather than in database stored procedures they impact the information solution architecture.
In other words, as organizations move to more shared cross-process software and data services the concept of “applications” starts to break down. Applications and services will be contained in the larger architectural solutions which combine elements from business, information and technical architectures. As this happens, the discipline and roles related to application architecture (especially software service design) will become increasingly more critical to application solution success. And, BTW, this also means the there is a trend to move away from project-based “application delivery” of solutions to a greater focus on delivering “products” in the form of shared services across processes.
All that said, you should expect for the term “application” – despite it’s increasing vagueness – to continue to be used by vendors and inside of IT organizations any time soon….
*Available to Gartner clients or for a fee
Category: Uncategorized Tags:
by Michael Blechar | September 30, 2010 | Submit a Comment
People sometimes ask me where I get my ideas from for my written research and presentations. The fact is that most ideas I get come from daily events in my life which appear to have nothing to do with computers but, in fact, help spark related ideas in my woe-begotten head. One constant source of fodder comes from listening to religious preachers. Take, for example, this past Sunday where there was a sermon which addressed the “legacy left by our forefathers” in terms of church doctrine. And, more specifically, how the term “legacy” means “gift from the past”. Needless to say, as a former maintenance programmer and database administrator this is hardly the mental image which comes to my mind when I hear the word “legacy”! I can recall several times where I was told that I was “inheriting the XYZ program” – hardly something I felt exciting about as an heir to the inheritance!
Yet, clearly, organizations have millions of dollars invested in “legacy applications and data”, and most are crucial to running the business of the enterprise. So, was I merely falling into the “not invented here mindset” focused on my small piece of the total value of the legacy? Perhaps – especially when inheriting a program from an overly creative and bored programmer who decided to turn an employee benefits update program into a “novel about zoos” with verbs, data and paragraph names like “Move orangutan to monkey-cage” and “Perform feed-the-lions” (I’m not making this up!).
But it is not the my purpose in writing this blog to talk about renegade programmers; it is to discuss how organizations need to think about their application and data architectures both for now and in the future. And, as a reminder, since today’s application purchase and development is tomorrow’s legacy this issue goes beyond gifts from the past.
The higher the quality and standardization of the applications and data – and the resolution of the governance issues that go with the sharing and reuse of them – the more likely that legacy becomes a future asset worth inheriting. That is not to say that all applications and data require robust architecture and management – organizations need a variety of approaches to application development which best match the business needs and objectives. In most cases this will be a “good-enough” set of architectural principles and guidelines to best meet the need.
Three important ways to build for future value include:
1)Fill the Enterprise Solution Architect role to help create the patterns, frameworks, standards and guidelines to be applied to projects as part of a transition strategy which moves the current application portfolio forward in a logical manner to meet the needs of the envisioned future solution architecture.
2)Where possible promote the use of service-oriented architecture (SOA) approaches to development and fill the new/evolving role of Application Architect to perform service design at a detailed level in a manner which makes software reusable across projects and processes.
3)Ensure that enterprise information management disciplines are being followed and where possible promote master data management (MDM) initiatives to improve data quality and make data more accessible to future applications.
And, decide what type of legacy you want to leave as an individual. If you are not being recognized for, or fulfilled by, your efforts consider making a change. As Benjamin Disraeli once said, “Life is too short to live small”!
Category: Uncategorized Tags:
by Michael Blechar | August 28, 2010 | Submit a Comment
I have recently been very active, along with my colleague Brian Gammage, in writing on the topic of the “cradle to grave” threats and opportunities surrounding technology assets using a new Gartner brand of research called the “IT Market Clock” (see “Introducing Gartner’s IT Market Clock*” and “Understanding Gartner’s IT Market Clocks, 2010*”). The IT Market Clock is designed to help enterprises balance their investments across portfolios of IT assets. Although primarily targeted at enterprise buyers of technology, the IT Market Clock also is useful to providers when considering how to manage their portfolios, how to support their customers, and the best ways to monetize their products.
At the heart of this research is the principle that as markets age, they go through stages where there can be increased opportunities to invest in a given technology market, but as the market gets more commoditized the vendors and products start to fall away, creating risk. I explore these opportunities and risks in my research note “How to Evaluate IT Market Clock Technology Opportunities and Risks, 2010*”.
It is possible to show on the IT Market Clock multiple markets and technologies in terms of where they stand on terms of consolidation, opportunities and threats (for example, see “IT Market Clock for Application Development, 2010*”). An important point here is that organizations should not evaluate technologies in a vacuum, since they tend to have interdependencies which impact the decision of when and how to divest from that given technology.
Consider the following examples from my research note “Identifying IT Market Clock Interdependencies*”.
The decision to upgrade from the current release of an application package to a newer release needs to factor in how the differences impact the business users of the package, as well as how the architecture of the new version impacts the technology platform. Or, perhaps the organization would like to change from one requirements management tool to another, but the original tool is integrated to modeling and testing tools as part of a vendor tool suite and the new tool might lack the value-added integration (or ability to track compliancy) which the original tool had. Another example is where phasing out of a development fourth generation language (4GL) is only possible if the applications built in that 4GL are no longer being used.
In other words, in many cases it is not only the interdependencies of tools within the technology architecture which impact the decision of when and how to divest from a given technology, but also the interdependencies with the secondary solutions (the application, information and business architectures).
So, remember to look at all potential interdependencies when planning changes in technology since the impact might be far broader than you anticipated. Cross-architecture collaboration helps a lot in understanding the ramifications of divesting from technologies.
*Available to Gartner clients or for a fee
Category: Uncategorized Tags:
by Michael Blechar | July 23, 2010 | Submit a Comment
Organizations are increasing expecting IT to rapidly deliver new applications – and ensure they can be changed in a more agile manner – than in the past. Service-oriented architecture (SOA) standards and technologies are helping to drive these improvements, but unless IT also changes its disciplines this will be constrained.
I have just completed working on a new “Analyst Picks” column for the week of 7/26 which list key Gartner research which addresses these issues and thought I’d post them here in my blog. Five key things which organizations need to focus on in terms of selecting the most appropriate approach to AD project, especially when moving to service-oriented development of applications (SODA), is the following:
1) Requirements come in many categories, types and formats — and, in fact, may not even be "required." This research examines what most Organizations need to be clear on what is considered to be "requirements," (models, text, standards, patterns and frameworks, etc) how they are captured, and how they are conveyed to projects to ensure the delivery solutions which meet business expectations.
The Perspective of "Requirements" Varies By Role and Context*
2) To minimize application development and maintenance cost and effort, while maximizing quality and agility, organizations should have multiple project approaches to implementing requirements, ranging from ad hoc solutions to highly architected ones.
Selecting the Best Project Approach to Application Development and Composition*
3) Determining what "just enough" means requires organizations to choose a development process, but that’s "not enough." It’s also crucial to define the level of rigor in any process, and that’s based on the deliverables associated with the particular method.
‘Just Enough Process’ Is Built on Deliverables*
4) There’s no one "right" methodology for an applications group to use. However, by juxtaposing process formality with the pace of business change, a clearer view of which methods to use becomes more apparent. Best Development Methods: A Scenario View*
5) Many organizations don’t completely understand what "agile," "iterative" and "waterfall" mean when it comes to software method selection. There are times when each is appropriate and is a reasonably clear framework to follow for selection.
Waterfalls, Products and Projects: A Primer to Software Development Methods*
*Available to Gartner clients or for a fee
Category: Uncategorized Tags:
