Visitors

free counters

Tuesday, June 29, 2010

Murder Sparks Effort for Stiffer Security at Convenience Stores

June 28, 2010 - KANSAS CITY -- The murder of a 7-Eleven convenience store clerk at a store in South Kansas City has sparked a signature drive to change a state law dealing with convenience store safety.

The family of Tony Singh, a 35-year-old father of two who was shot to death March 17 during a holdup of the 7-Eleven on Banister Road, has spearheaded a petition drive to gather 100,000 signatures in support of what they are calling the "Tony Singh Bill," a measure to improve safety at gas stations and convenience stores.

The bill proposes that no one would be allowed to work in a convenience store alone past 10 p.m., bullet proof security glass would be required around cashier station, requires the installation of "panic" buttons to notify police in case of a robbery, and mandates that a security guard be present at the store. If the criteria are not met, the store would not be allowed to stay open past 10 p.m.

After meeting with the family, Mayor Mark Funkhouser has pledged his support and to creating "a safe community for the retail and small businesses."


Monday, June 28, 2010

Visionary Thinking

Anthony Galie descrides how to program yourself for success

Anthony Galie at the Orange County Center for the Performing Arts describing the effects of "Visionary Thinking"

Anthony Galie describes how to visualize your goals

Programming Yourself for Success

Anthony Galie describes a simple way to program your own Subconscious mind


*If you received this via email, click on the link at "Posted by ECGMA to ECBeez Blog" to view the blogpost"*

Friday, June 25, 2010

10 Steps to optimize Sharepoint Performance

Eric Shupps


May 24, 2010 (Network World)
SharePoint, the fastest growing product in Microsoft's history, is used to store reams of documents, meaning application performance is a key component for successful SharePoint deployment and adoption. Here are 10 steps to improve the performance of your SharePoint servers.

Step 1: Separate user and database traffic
A common misconception is that servers connected to a high-speed network segment will have plenty of bandwidth to perform all required operations. But SharePoint places a tremendous amount of demand on SQL -- each request for a page can result in numerous calls to the database, not to mention service jobs, search indexing and other operations.
10 things we love about SharePoint 2010
In order to mitigate the conflict between user and database traffic, connectivity between front-end servers and SQL should be isolated, either via separate physical networks or virtual LANs. Typically this requires at least two separate network interface cards in each front-end Web server with static routes configured to ensure traffic is routed to the correct interface. The same configuration may also be applied to application and index server.

Step 2: Isolate search indexing
A typical medium server farm consists of one or more Web front-end servers, a dedicated index or application server and a separate SQL database server. Search traffic initiated by the index server must be processed by the same servers responsible for delivering user content. In order to prevent search and user traffic from conflicting, an additional server may be added to the farm, which is dedicated solely to servicing search queries (in smaller environments, the index server may also serve this function). The farm administrator would then configure the search service to perform crawls only against this dedicated server. This configuration may reduce traffic to the Web front-end servers by as much as 70% during index operations.

Step 3: Adjust SQL parameters
One quick way to avoid future headaches is to provision the major SharePoint databases on separate physical disks (or LUNs if a storage-area network is involved). This means one set of disks for search databases, one for temporary databases and still another for content databases. Additional consideration should be given to isolating the log files (*.ldf). Although these do not incur the same level of I/O as other files, they do play a primary role in backup and recovery and they can grow to several times the size of the master database files.
Another technique is to proactively manage the size and growth of individual databases. By default, SQL grows database files in small increments, either 1MB at a time or as a fixed percentage of database size (usually 10%). These settings can cause SQL to waste cycles constantly expanding databases, and prevents further data from being written while the databases are expanding. An alternative approach is to pre-size the databases up to the maximum recommended size (100GB) if space is available and set auto growth to a fixed size (e.g. 10MB or 20MB).

Step 4: Defragment database indexes
SQL Server maintains its own set of indexes for data stored in various databases in order to improve query efficiency and read operations. Just as with files stored on disk, these indexes can become fragmented. It is important to plan for regular maintenance operations, which includes index defragmentation. Special care should be taken to schedule these types of operations as they are resource-intensive and, in many cases, can prevent data from being written to or read from the indexes.

Step 5: Distribute user data across multiple content databases
Most SharePoint data is stored in lists: tasks, announcements, document libraries, issues, picture libraries, and so forth. A great deal of this data is actually stored in a single table in the content database associated with the site collection. Regardless of how many sites and subsites are created within the SharePoint hierarchy, each site collection has only one associated content database. This means that a site collection with thousands of subsites is storing the bulk of the user data from every list in every site in a single table in SQL.
This can lead to delays as SQL must recursively execute queries over one potentially very large dataset. One way to reduce the workload is to manage the mapping of site collections to content databases. Administrators can use the central administration interface to pre-stage content databases to ensure that site collections are associated with a single database or grouped logically based on size or priority. By adjusting the 'maximum number of sites' setting or changing database status to "offline", administrators can also control which content database is used when new site collections are created.

Step 6: Minimize page size
For SharePoint users connected to the portal via a LAN it is easy to manage content and find resources, but for users on the far end of a slower WAN link the heavyweight nature of a typical SharePoint page can be a real performance-killer.
If you have many remote users, start with a minimal master page, which, as the name implies, removes unnecessary elements and allows designers to start with a clean slate that only contains the base functionality required for the page to render correctly.
Second, most SharePoint pages contain links to supporting files, including JavaScript and style sheets, which require additional time to retrieve and execute. Designers can alter how SharePoint pages retrieve these files using a technique called "delayed loading", which essentially loads the linked files in the background while the rest of the page is rendering.

Step 7: Configure IIS compression
SharePoint content consists of two primary sources -- static files resident in the SharePoint root directories (C:\Program Files\Common Files\Microsoft Shared\12 for 2007 and \14 for 2010) and dynamic data stored in the content. At runtime, SharePoint merges the page contents from both sources then transmits them inside an HTTP response to the requesting user. Internet Information Server (IIS) versions 6 and 7 both contain various mechanisms for reducing the payload of HTTP responses prior to transmitting them across the network. Adjusting these settings can reduce the size of the data transmitted to the client, resulting in shorter load times and faster page rendering.
IIS compression settings can be modified from a base value of 0 (no compression) to a maximum value of 10 (full compression). Adjusting this setting determines how aggressive IIS should be in executing the compression algorithms.

Step 8: Take advantage of caching
Much of the content requested by users can be cached in memory, including list items, documents, query results and Web parts. Site administrators can configure their own cache profiles to meet different user needs. Anonymous users, for example, can be assigned one set of cache policies while authenticated users are assigned another, allowing content editors to get a more recent view of content changes than general readers. Cache profiles can also be configured by page type, so publishing pages and layout pages behave differently, and administrators have the option to specify caching on the server, the client, or both.
In addition, the SharePoint Object Cache can significantly improve the execution time for resource-intensive components, such as the Content Query Web Part. For example, large objects that are requested frequently, such as images and files, can also be cached on disk for each Web application to improve page delivery times.

Step 9: Manage page customizations
SharePoint Designer is a useful tool for administrators and power users but page customization can be harmful to overall performance. When customization occurs, the entire page content, including the markup and inline code, is stored in the database and must be retrieved each time the page is requested. This introduces relatively little additional overhead on a page-by-page basis, but in larger environments with hundreds or even thousands of pages, all that back-and-forth to the database can add up to significant performance degradation.
To prevent this problem, administrators should implement a policy that restricts page customizations to only those situations where it is absolutely necessary. Site collection and farm administrators also have the option to disable the use of Designer or, when necessary, use the 'reset to site definition' option to undo changes and revert back to the original content.

Step 10: Limit navigation depth
One of the most significant design elements on any portal site is the global, drop-down, fly-out menu at the top of each page. It seems like a handy way to navigate through all the various sites and pages -- until it becomes so deep and cluttered that all ability to navigate beyond the first few levels is lost completely. Even worse, fetching all the data to populate the navigation menus can be resource-intensive on sites with deep hierarchies.
SharePoint designers have the ability to customize the depth and level of each navigation menu by modifying the parameters for the various navigation controls within the master page. Administrators should limit that depth to a manageable level that does not impact performance.

Eric Shupps is a SharePoint MVP who specializes in SharePoint performance to help organizations better understand the different ways and places SharePoint performance can be improved. This article was written in partnership with Idera.

Read more about data center in Network World's Data Center section.

Thursday, June 24, 2010

SOA Definition and Solutions

From: www.cio.com

SOA Definition and Solutions

– CIO

March 19, 2007 

What is Service-Oriented Architecture (SOA)?

SOA is a confusing term because it describes two very different things. The first two words describe a software development methodology. The third word, architecture, is a picture of all the software assets of a company, much as an architectural drawing is a representation of all the pieces that together form a building. Therefore, service-oriented architecture is a strategy that proclaims the intention to build all the software assets in the company using the service-oriented programming methodology.

What is a service?

Services are software chunks, or components, constructed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed in chunks that business people can understand rather than as an arcane application such as ERP or CRM.

At the core of the services concept is abstraction, the idea that you can assemble software code into a chunk meaningful enough that it can be shared and reused in many different areas of the company. For example, there is a lot of software code that goes into creating an automated task such as sending a query to a credit reporting website to find out if a customer qualifies for a loan. But if the programmers at a bank can abstract all that code to a higher level—that is, take all the code that was written to perform the credit rating check and package it into a single unit called "get credit rating"—the programmers can reuse that chunk the next time the bank decides to launch a new loan product that requires the same information rather than having to write the code from scratch.

Developers create the abstraction by building a complex wrapper around the bundled code. This wrapper is an interface that describes what the chunk does and how to connect to it. It's an old concept that dates back to the 1980s, when object-oriented programming first appeared; the only difference is that today, the ambition for the size and sophistication of these software objects is far more grand.

For example, at telecom company Verizon, the service called "get CSR" (get customer service record) is a complex jumble of software actions and data extractions that uses Verizon's integration infrastructure to access more than 25 systems in as many as four data centers across the country. Before building the "get CSR" service, Verizon developers who needed that critical lump of data would have to build links to all 25 systems—adding their own links on top of the complex web of links already hanging off the popular systems. But with the "get CSR" service sitting in a central repository on Verizon's intranet, those developers can now use the simple object access protocol (SOAP) to build a single link to the carefully crafted interface that wraps around the service. Those 25 systems immediately line up and march, sending customer information to the new application and saving developers months, even years, of development time each time they use the service.

There are many different ways to connect services, such as custom programming links or integration software from vendors, but since 2001, a set of software communication mechanisms known as web services, which are built upon the ubiquitous World Wide Web, have become an increasingly popular method for linking software components together.

What's the difference between SOA and web services?

SOA is the overarching strategy for building software applications inside a company—think of an architectural blueprint—except that in this case, the architecture calls for all the pieces of software to be built using a particular software development methodology, known as service-oriented programming. Web services, meanwhile, are a set of standard communication mechanisms built upon the World Wide Web. Web services are a linking and communications methodology. SOA is an overall IT strategy.

How do I know whether I should adopt SOA as a strategy?

Because it is an architectural strategy, SOA involves much more than merely building software. Creating an architecture based on a portfolio of services asks that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. It also requires a willing CEO and executive staff to pave the way for IT to dive in to the core business processes of the company. Understanding those processes and getting buy-in on enterprise sharing are the keystones of SOA-based business transformation.

Governance is critical. For services to be reused across the company, there must be a single, centralized software development methodology so that different areas of the business don't build the same service in different ways or use linkages that are incompatible. There must be a centralized warehouse, or repository, so that developers will know where to look for services—and so IT will know who is using them. The services must be well documented so that developers will know what they are for, how to link to them and the rules for using them. (For example, some companies charge fees to use the services and create performance agreements to make sure the services work well and don't put too much load on the corporate network.)

Most companies that have progressed along the path to SOA have created a centralized architecture group to choose processes that will be service enabled and to consult with different areas of the company to build the specific services. The centralized group also creates a convenient mechanism for governance. If all service requests have to go through the architecture group, the service development methodologies, projects and performance agreements can be more easily managed.

The companies that have had the most success with SOA so far are those that always have success with technology: big companies with big IT budgets whose business is technology-based (think telecom and financial services). They also tend to have supportive, technologically sophisticated business leaders. For companies without these advantages, SOA may not be the panacea it's being made out to be.

For smaller companies, for companies that have made big bets on integrated application suites and for companies that already have solid application integration strategies in place, SOA isn't a "when," it's an "if." CIOs need to pursue an SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of SOA's most important benefits) or may fail outright.

What are the advantages of SOA?

First, put the benefits of SOA in perspective. SOA is a scythe that slices through complexity and redundancy. If your company is not large or complex—i.e., more than two primary systems that require some level of integration—it's not likely that SOA will provide much benefit. Lost in all the hype about SOA today is the fact that the development methodology itself brings no real benefit—it's the effects that it has on a complex, redundant infrastructure that bring the rewards. Architects say there is more work involved in creating a good service-oriented application than there is in doing traditional application integration. (Surveys show consistently that SOA is being used for traditional application integration at most companies.) So there is actually an extra cost being generated by SOA development up front. For there to be a benefit from that work, therefore, it must eliminate work somewhere else, because the methodology in and of itself does not create business benefit. Before considering whether SOA has benefits, you first must determine whether there are redundant, poorly integrated applications that could be consolidated or eliminated as a result of adopting SOA. If that's the case, then there are some potential benefits.

To get the entire picture of benefits being sold with SOA, you have to look at it on two levels: first, the tactical advantages of service-oriented development and second, the advantages of SOA as an overall architecture strategy.

Advantages of service-oriented development:

1. Software reuse. If the bundle of code that constitutes a service is the right size and scope (a big if, say SOA veterans), then it can be reused the next time a development team needs that particular function for a new application that it wants to build. For example, a telecom company may have four different divisions, each with its own system for processing orders. Those systems all perform certain similar functions, such as credit checks and customer record searches. But because each system is highly integrated, none of these redundant functions can be shared. Service-oriented development gathers the code necessary to create a version of "credit check" that can be shared by all four systems. The service may be a wholly new chunk of software, or it may be a composite application consisting of code from some or all of the systems. Regardless, the composite is wrapped in a complex interface that hides the complexity of the composite. The next time developers want to create an application that requires a credit check, the developers write a simple link to the composite application. They don't have to worry about linking with the individual systems—indeed, they don't need to know anything about how the code has been bundled or where it comes from. All they need to do is build a connection to it.

In a company that constantly builds new systems that rely on similar functionality—an insurance company with many different divisions, each with slightly different products, for example, or a company that is constantly acquiring new companies—the time saved in developing, testing and integrating that same bit of software functionality can add up.

But reuse isn't assured. If developers in other parts of the company don't know that the services exist, or don't trust that they are well built, or development methodologies differ around the company, the service may languish as a one-off. Companies that get reuse have developed governance mechanisms—such as centralized development teams, a single development methodology and service repositories—to increase the chances for reuse.

But sometimes the service just isn't designed properly. Perhaps it doesn't perform enough operations to be widely applicable across the company, or perhaps it tries to do too much. Maybe the developers didn't take into consideration all the different ways that others might want to use the service in applications. SOA veterans say that sizing services properly—also known as granularity—is as much art as science and that poor granularity can dramatically reduce the possibilities for reuse. Research company Gartner estimates that only 10 percent to 40 percent of services are reused.

2. Productivity increases. If developers reuse services, that means software projects can go faster and the same development team can work on more projects. Integration becomes a lot cheaper (at least 30 percent cheaper, according to estimates by Gartner) and faster, too, taking months off development cycles for new projects. Shadman Zafar, Verizon's senior vice president for architecture and e-services, says his catalog of services lets him skip forming a project team for the development of a phone-line ordering process, because the services necessary to compose the process were already in place. "With point-to-point integration, we would have had a central project team to write the overall integration, and local teams for each of the systems we needed to integrate with. With [the phone-line process], we had a single team that was focused almost entirely on end-to-end testing," he says. That saves time and resources and improves the quality of new applications, because testing is no longer the last hurdle of an exhausting application development process; instead, it's the focus.

3. Increased agility. Even if services will not be reused, they can offer value if they make IT systems easier to modify. At ProFlowers.com, for example, there are no redundant applications or multiple business units clamoring for services. But splitting the flower ordering process into discrete services means each component can be isolated and changed as needed to handle the spikes in demand that occur around holidays, according to ProFlowers CIO Kevin Hall. When ProFlowers had a single, monolithic application handling the process, a single change in the process or a growth in transaction volume (on, say, Valentine's Day) meant tearing apart the entire system and rebuilding it.

In the new system, a server farm responds to spikes in activity during each phase of the ordering process by transferring storage capacity to the specific service that needs it most. The system is much more predictable now, and there have been no outages since the service-enabled process was rolled out beginning in 2002, according to Hall. "Because we can scale horizontally [more servers] and vertically [splitting up services], I don't have to buy all the hardware to serve every service at its peak load," he says. "You don't have to be able to eat the elephant in one bite anymore."

Advantages of an SOA strategy:

1. Better alignment with the business. SOA is the big picture of all the business processes and flows of a company. It means business people can visualize, for the first time, how their businesses are constructed in terms of technology. When IT projects are put in terms of business activities and processes rather than complex software applications, business people can better appreciate and support IT projects. "When I said we have 18 slightly different versions of 'credit check' buried inside different applications in different agencies," says Matt Miszewski, CIO for the state of Wisconsin, "the agency heads could understand why having all those different versions was a problem, and they could support creating a single version that everyone could use." The grand vision for SOA is that when IT fully service enables the major processes of a business, business people will someday be able to take control of modifying, mixing and matching the different services together into new process combinations on their own. But that vision is still many years away.

2. A better way to sell architecture to the business (and IT). Enterprise architecture has long been the concept that dared not speak its name. Some CIOs go to great lengths to avoid using the term with their business peers for fear of scaring, alienating or simply boring them to death. Enterprise architecture has always been a big, difficult and expensive undertaking, and its ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets do not make the business obviously more flexible, capable or profitable. As a result, IT architecture efforts often fail or become completely IT-centric. SOA provides the value to the business that in the old enterprise architecture was rarely more than a vague promise. Reuse, improved productivity and agility in IT and a software infrastructure tuned to specific business processes are the lures to sell an enterprise architecture effort to the business. But remember that architecture is not for everyone. Small companies or highly decentralized companies may not be able to justify a centralized staff of project managers, architects and developers.

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed, and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That's why I like the project route, because otherwise you don't have anything tangible to sell to anyone about why you're doing this."

While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn't provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."

By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We've had hiccups but could take corrective action because the issue wasn't that big," he says. "If you break it into simpler pieces, it's more easily digestible."

How do I know which services will provide the most value for my investment?

When in doubt, start with processes that involve customers, directly affect revenue and address a specific pain point in the business. A 2006 survey by the Business Performance Management Institute found evolving customer needs and preferences to be the top driver in business process change or the introduction of new applications, followed by competitive threats and new revenue opportunities. (Cost savings was a distant fourth.) "Externally facing applications are the ones that provide the most business value, and they have a good set of change requirements that come up very often," says Daniel Sholler, vice president of research for Gartner. "If you can improve those applications by 10 percent, it's better than improving lower-level applications by 50 percent." Of course, adds Sholler, SOA may not provide more value than, say, a good packaged application. "But if it's something you would have to build yourself anyway, you need to do it service-oriented," he says.

How will SOA affect my IT group?

If you have a decentralized company, be prepared for a struggle. SOA drives centralization. Indeed, it demands it. "You have to have someone heading it up, and you have to have one individual or small team manage the architecture," says Mike Falls, senior system engineer for Fastenal, an industrial and construction supply company. "If each team is left to itself, they may each come up with different ways of building services. You need one group, one set of research and someone to make sure the development groups are sticking to the service development methodology."

As the service portfolio grows, the development process may begin to look like an assembly line. "It becomes a factory," says AEP's Wissner. "You have these different project teams that you funnel work through, and they can grow and shrink as required."

Once the SOA factory gets ramped up, expect to add more project managers, business analysts and architects as the productivity of the developers increases, says ProFlowers' Hall. "Two developers can now do the work of six," he says. "That means the architects and project managers are running to keep up with the output of the engineers. We are probably doing 50 percent more work than we did three years ago."

Those programmers need to understand object-oriented programming and distributed applications—and that means an investment in training. According to the CIO/Computerworld survey, only 25 percent of respondents have the staffs they need for SOA—49 percent said they are planning or have training programs in place for current staff to bring them up to speed.

What's the Next Step?
Want to learn more about SOA, Web services and related software development technologies? We have plenty of resources:


SOA: Think Business Transformation, Not Code Reuse

SOA: Think Business Transformation, Not Code Reuse

– Randy Heffner, CIO

February 18, 2010

The worst CIO misunderstanding about service-oriented architecture (SOA) is thinking of it as only another technical initiative for software reuse. Although SOA's reuse potential is real and good, its business impact goes much further: In Forrester surveys, 38 percent of Global 2000 SOA users say they are using it for strategic business transformation. SOA's true source of power is in its business design models, not its technology — and this means that SOA provides a broad foundation for a much larger shift in business technology (BT) architecture that goes far beyond SOA itself. By correctly understanding SOA, CIOs can lead their organizations on a solid and well-managed path toward a strategic technology future and greater business value.

[CIO.com's resident expert Dan Rosanova dives deep and provides expert advice and analysis about SOA in his blog SOA Advisor]

Forrester defines SOA as a business-focused approach to solution design and software architecture. By providing open, flexible access to the business capabilities and transactions buried within an organization's applications, SOA makes it easier to adapt existing software to new business requirements. CIOs who think of SOA merely from a technology perspective will miss this business view of SOA, and they'll miss an opportunity to lead their organizations forward. SOA is the foundation of a much broader shift in the future of business-focused IT architecture, which means that those who get SOA wrong will have a poor business foundation for many years to come.

Sixty-eight percent of enterprises say they are using SOA or will be using it by the end of 2010. Fifty-six percent are using SOA now, and that number jumps to 74 percent when considering only Global 2000 organizations. All this SOA usage is not just industry hype and experimentation, either. SOA has been delivering tangible results that make IT executives want more of it: 52 percent of current enterprise SOA users say it has delivered enough benefit that they plan to expand its use, while only 1 percent of SOA users say they are cutting back on SOA because they see little or no benefit. For the rest, it's either too early to tell or they are struggling to get the benefits — often because they approach it as only a technology.


The key points CIOs must understand about SOA are:

SOA aligns your software with your business. While it is true that SOA is fundamentally an approach to software architecture and design, which makes it sound tech-oriented, the most important SOA concept is to design software around the business capabilities you need to run your organization. Each SOA-based business service performs a complete business unit of work, hiding the complexity of your IT applications behind a pluggable digital software interface for a specific, targeted business capability such as "submit order" or "distribute sales lead."
SOA creates a portfolio of business capabilities. By designing for the business capabilities your organization needs, a business-oriented approach to SOA creates a coherent portfolio of business services that directly reflect the design of your organization's major business transactions and processes. These services build upon and leverage your existing base of siloed and overlapping applications, insulating your business from the existing complexity by providing a service layer where business alignment is built directly into your software.
SOA brings business capabilities where they are needed. With a portfolio of SOA business services, your organization can quickly connect your business capabilities to any business process, employee, customer, partner, supplier, government entity, mobile device, or anything else as needed to adapt to changing business conditions and implement business improvements.
There's more: SOA's business services provide a foundation for further innovation and business optimization. Four examples include:
BPM for business responsiveness. Business process management (BPM) and business activity monitoring (BAM) solutions can use the business data flowing through your SOA services for business visibility and rapid response.
Event processing for early warning. Event processing solutions can identify patterns in business service flows to provide early warning for potential business problems.
Predictive analytics for action that anticipates future problems. Predictive analytics can operate over near-real-time flows of data from your SOA services or data services, or from event streams flowing through SOA infrastructure to event-processing solutions, to predict future business problems from patterns that emerge from mathematical modeling of system behavior.
Rules and policy for business flexibility. Business rules and policy management technologies can provide the means to quickly adapt the operation of the digital business represented by your business services.
There is benefit in SOA itself, and there is further benefit in the foundation for business process intelligence and adaptability that SOA provides. It is not simply about using SOA together with other technologies: Unless SOA is the foundation of a larger architectural vision, adding on other technologies only creates more technology integration issues. Building on top of SOA, Forrester integrated vision for Business Capability Architecture, Digital Business Architecture, Dynamic Business Applications, and more embody a future where the architecture of your solutions matches the design of your business. SOA is the foundation for achieving a broader strategic future.

Randy Heffner is a Vice President at Forrester Research, serving Enterprise Architecture professionals. He is a leading expert on architectures and design approaches for building enterprise applications that are secure and resilient in the face of continuous business and technology change.

SOA Transformation and IT Culture Shock

SOA Transformation and IT Culture Shock

(Service Oriented Architecture)


By Eric Roch, National Practice Director, Perficient , 06/26/2006


For most IT organizations, SOA is a culture shift from a technology-driven application development style (focused on features and functions) to a business-driven style (focused on business processes and underlying services). One of the major factors in early SOA success is the speed at which a company can shift to a SOA development style, which is correlated to current IT skills and development processes in place.


For IT organizations still building applications using a waterfall methodology with procedural languages, an SOA approach will be a culture shock. The waterfall approach involves users in the requirements phase and then again during user acceptance testing. There is typically a user and designer disconnect between the requirements phase and user acceptance – often leading to a big surprise at the end. Rapid application development techniques help by involving users with design through the use of prototypes. Prototypes, however, are typically a requirements deliverable for the user interface and do not give much visibility or flexibility to the underlying business process.

An Object-oriented analysis and design (OOA/OOD) style is more consistent with SOA in that OOA/OOD has specific deliverables that can be applied to interface design, separation of concerns, and collaboration. Object-oriented systems are similar to SOA in that they have well defined and encapsulated interfaces. Also, UML diagrams most often used for OOA/OOD can be applied to SOA design. However, OOA/OOD is primarily focused on class design using a class hierarchy that supports inheritance. SOA is a loosely coupled model with higher level abstractions – at a business-service level versus a class level. SOA is actually more like component-based development (CBD). The CBD and SOA similarities include reuse through assembling components, interface definitions and loose coupling.

The path to SOA depends on your starting point in terms of skills and development approach. But, since the design goal for SOA is business service reuse and business process agility, it is obvious that the business users need to be more involved than in past development approaches. While use cases and activity diagrams can be explained to users, it is difficult to train users to use such tools to model business processes themselves or at times to even effectively collaborate with IT to model processes. Also, UML does not provide a means to analyze, simulate and optimize business processes. SOA will add little or no value if the underlying business processes are not improved.

There are several ways to bridge the culture gap to SOA. First, IT can start to design and build services, governance processes, organizational skills and service's infrastructure in a bottom-up style. A bottom-up approach examines discrete applications and creates services specific to the application. The advantage of this approach is that IT can build their internal support mechanisms for SOA without exposing weaknesses to the business. The disadvantage is that SOA will not be focused on improving business processes and adding business value. The bottom-up approach is however often pragmatic when the learning curve to SOA is high.

A top-down approach builds a services catalog based on projects in the IT portfolio and strategic business drivers. Funded projects in the IT portfolio should be examined to determine if SOA will reduce costs and create business value. A SOA roadmap and services catalog is build based on core business processes, process effectiveness and business value. The roadmap is business driven, so the architecture is defined to support the business objectives.

When approaching SOA in a top-down manner with the goal of enterprise transformation, one must consider the current culture of the IT environment. The primary question is how collaboratively does IT work with the business to build systems? If the answer is not very, then a bottom-up approach is less risky.

IT can also start SOA in more of a Business Process Management (BPM) style. This can be accomplished by exposing the business to process modeling without an emphasis on services or enterprise-wide SOA transformation. For example, I recently worked with a client to understand and optimize their order to cash process. This involved traditional as-is/to-be process modeling with the intent on process optimization. As a result of this project several services where identified though process decomposition. We are now creating these services in more of a bottom-up approach without a great deal of visibility to the business at this stage.

Moving to a top-down, business driven approach quickly ensures that SOA generates value early in the rollout. Providing business value early creates momentum and further investments. However, exposing SOA to the business too quickly can result in early failures and disenchantment with the technology and IT's ability to deliver on the SOA promise. The initial approach should be based on the current IT culture and skills. Skills can be built using a bottom-up approach and collaboration between IT and the business can be improved through BPM techniques.

About the Author

During his more than 20 years of experience in Information Technology, Eric Roch has worked in roles such as executive level management, technical architect, and software development in top tier technology organizations including TIBCO Software (Director of Professional Services) and Deloitte Consulting. Recently, Eric served as CTO of a pure-play SOA consultancy and is currently Chief Technologist and National Practice Director for Business Integration at Perficient Inc. (NASDAQ: PRFT). In his role with Perficient, Eric develops strategic plans for business integration and SOA for Fortune 500 companies. He is also responsible for the commercialization of Perficient's methodology and software for SOA services delivery. As an IT industry speaker and author, Eric has been invited to speak at numerous industry events and written for leading industry publications. Eric earned his Bachelor of Science in Computer Systems from City University of Bellevue, Washington, and Master of Science in Management of Technology from the University of Maryland.

More by Eric Roch

About Perficient

Perficient is a leading information technology consulting firm serving clients throughout the United States. We are experts in designing, building and delivering business-driven technology solutions. We help our clients gain competitive advantage by using Internet-based technologies to make their businesses more responsive to market opportunities and threats, strengthen relationships with customers, suppliers and partners, improve productivity and reduce information technology costs.


What is IT Transformation?

http://itransform.abstraction.com/2009/03/what-is-it-transformation.html

It's one thing is to sell to your company the idea that technology can be used to leverage competitive strengths and that the future belongs to those who use modern technology more effectively, and another to precisely define what you mean by IT Transformation. If you fail to explain what IT Transformation is truly about, you could risk ending up with projects that ultimately miss the mark.

For example, while IT Transformation encompasses the investment strategies and tactics needed to leverage modern technologies by refreshing the old with the new, it shouldn't be confused with Business Process Reengineering (BPR). Yes, BPR may well be either a driver or a consequence of IT transformation, but IT Transformation is not simply an exercise in reengineering. Just replacing something old with something new, such as adding a newer version of a module does not a transformation project make. Even something with a bigger scope such as changing a database vendor, while an important effort, it's one that's just strictly tactical in nature.

Lastly, transforming basic administrative chores that are similar to those found in millions of other companies is certainly worthy of respect and support, but this type of effort is not IT Transformation. That new ERP system you plan to deploy in your company? You are probably better off hiring an ERP vendor, or a very qualified third party to deal with this transformation. My point is this: not every technology project, regardless of its size, is an IT Transformation project.

What then is an IT transformation project?

IT Transformation is more than mere optimization or modification of engineering components, but is rather a holistic revamp of the existing technology base used to support the company's mission-critical business. Ironically, IT Transformation is not about changing things for the sake of change, but about better aligning the IT system to the needs of the business. Indeed, based on the results obtained from an April 2000 conference held at MIT, 90% of attendees agreed that matching IT to strategic corporate requirements was the most important factor in a technology strategy; 80% believed that decreasing time to market for new products to be another major factor, and 70% felt managing IT with constrained resources was the driver.[1] This is a key point: IT transformation should ultimately be aligned with the strategic business view.

Because it deals with core business processes (by core, I mean revenue generating), technology transformation will intrinsically be both complex and risky. A failure in introducing this type of technology is not the kind of failure one can sweep under the rug.

IT Transformation deals with substantial core changes to the information systems technology, including the hardware and software of the system, the way the system is architected, and the way the data is structured and accessed. Technology in this definition also includes the algorithms, the IT command and control governance, and the actual and potential functionality supported by the system.

Software projects are hard to execute, and IT Transformation is bound to include a large software element at its core. Multiple studies done on the success rates of software projects reveal numbers that give pause. For example, the Standish Group has found that only about one-sixth of all projects are ever completed on time and on budget (and I suspect that figure includes many less complex projects); that nearly one third of all projects were canceled outright, and well over half were considered "challenged." Also, the typical challenged or canceled project was on average 189 percent over budget, 222 percent behind schedule, and contained only 61 percent of the originally specified features.[2]

In other words, IT transformation is serious business and is reminiscent of those prescription medicine advertisements shown on TV. Any consideration to apply it should come with a similar disclaimer.

Warning: Technology transformation may cause financial hemorrhaging in badly managed companies, resource bloating when done without professional supervision, and abnormal levels of bad media. Other symptoms might include executive insomnia, board irritability, aggression, growth suppression, and Tourette's syndrome associated with project delays and budgetary overruns. Consult expert advice prior to embracing this solution.

Well, it's one thing to understand what IT Transformation is all about and another to decide whether we need to take this type of medication.


My Photo
Name: Israel del Rio
Location: Atlanta, GA, United States

Israel has been recognized by Computerworld as one of their Premiere 100 IT honorees. Israel is a business and technology leader who has contributed the technology vision as key strategist and designer behind the enterprise technology roadmaps of large hospitality and travel companies. Israel has also have developed and deployed various mission-critical systems and in the process, he's been instrumental in creating and building effective and skilled development organizations.


Does an Operating Lease Make Sense For My Business?

By Mike Elton


An operating lease is a financing agreement where the term of the lease is shorter than the actual useful life of the equipment. For example, an airplane with an economic life of 25 years may be leased to an airline for five years on an operating lease. In business, operating leases are most commonly used to allow the business the use of equipment on a relatively short-term basis.

The determination of whether a lease is a finance (also called capital) lease or an operating lease is defined in the United States by Statement of Financial Accounting Standards No. 13 (FAS 13).


Operating leases can be more expensive than standard financing or leasing, since the lessor leases the equipment to the business for a fixed monthly amount, and also assumes the residual value risk of the equipment. One example of this in the consumer market is car leases. The consumer gets use of the vehicle for a specific time period, but at the end of the lease, must either return the vehicle to the dealer or assume a new lease.


Deciding whether a lease makes sense for your business depends on your firm's circumstances at the time you're making the decision. A few questions to ask yourself include how much you want to spend, how healthy is your cash flow, how long do you need the equipment, your history in caring for equipment, and what impact the lease will have on your taxes. Your accountant can help you determine if an operating lease has a financial benefit to your company.


An operating lease is most beneficial to companies when:

  1. Equipment will not be used long-term. It doesn't make sense to make a large cash outlay for equipment that will only be used for a short period of time.
  2. Your equipment will become outdated quickly. If technological advances in your industry tend to make your equipment obsolete every few years, a short term lease can help you stay up to date.
  3. Cash flow is tight. With a lease, you avoid a hefty up-front charge, and you can make payments as you generate cash flow with your new equipment.
  4. You want to protect your balance sheet. An equipment purchase is recorded in your balance sheet, which increase your debt and reduces your available cash. In contrast, most leases are not recorded as debt, and are treated as an operating expense.

You want the tax benefits of leasing. A lease may allow you to deduct your payments as operating expenses during the period in which you pay them. If you purchase equipment, you may be able to deduct the interest, as well as the cost of the depreciation. Consult your tax advisor for which situation is most advantageous for your business.


An operating lease may not be for everyone, however. Some things to keep in mind are:

  1. You are tied into payments for the length of the lease. A lease is a commitment to making the payments for the length of the contract.
  2. You won't build up equity.Buying something outright will give you equity. Just make sure that older equipment will still provide value for your business.
  3. With leasing, you may pay more over the long term. Lease payments include taxes, insurance and risk premiums, since the lessor is assuming the risk for the purchase.

Mike Elton is the Vice President of Sales for Advantage Leasing Corporation. Advantage Leasing is an equipment leasing company in Milwaukee, Wisconsin lending to business customers throughout the United States with financing needs valued between $5,000 and $200,000.

Article Source: http://EzineArticles.com/?expert=Mike_Elton

Mike Elton - EzineArticles Expert Author